**** BEGIN LOGGING AT Sun Sep 16 03:00:00 2012 Sep 16 03:01:54 i think it's pretty bad. jsstop reported over 7k nodes the other day Sep 16 03:02:19 yeah, right now it's got 5988 nodes... but it's not swapping from what i can tell. whole TP has 226MB Sep 16 03:03:15 after garbage collect, down to 202MB O.O Sep 16 03:04:04 on app first launch, it jumps to 1750 nodes, too, which is more than email. jeez Sep 16 03:04:16 well, that explains why it's poor on phones! Sep 16 03:05:03 fxspec06: so, a hybrid of DB8 + an array it is? to be fair, using db8 for everything will likely yield results which are just about as good. Sep 16 03:05:26 i wonder exactly what is causing so many nodes, though. apparently, it's the NODES that is the issue, and not the data itself... amirite? Sep 16 03:05:30 (under the assumption that people don't want to scroll through 10000s of tweets) Sep 16 03:05:51 the nodes are only in the HTML page? Sep 16 03:05:59 as in, they're DOM nodes? Sep 16 03:06:21 from JSTop, it reports nodes and handles Sep 16 03:06:31 so yeah, DOM nodes, apparently Sep 16 03:06:40 i have a ton of them according to JSStop Sep 16 03:06:46 and you're using the list with a flyweight? Sep 16 03:06:48 (quite literally) Sep 16 03:07:09 PulldownList has a flyweight, yes. Sep 16 03:07:22 where else do you show data? Sep 16 03:07:45 k, after loading 50~ tweets, nodes went from 1700 to 2300 Sep 16 03:07:57 hmm, so that's about 100 nodes / tweet. Sep 16 03:08:28 fxspec06: but loading another 50 shouldn't rais it that much, if any Sep 16 03:08:51 interesting to mention --: Sep 16 03:09:08 the other day i was looking in chrome, enyo creates its own "floatinglayer" div Sep 16 03:09:15 did you know that? well if you didn't, now you know Sep 16 03:09:58 yeah, i know. we have a feature which uses it IIRC Sep 16 03:10:00 what i was seeing was insane. i don't remember why, or how, or when it was happening, but basicalyl every time a list showed on the screen, a new floatinglayer object was inserted. but the old ones weren't getting removed Sep 16 03:11:28 that's not happening here, but i wonder if it's happening in another place. Sep 16 03:15:08 okay, i see. so, scratch that theory. Sep 16 03:15:34 fxspec06: try to load the list once for increasing sizes of amount of tweets. if it keeps rising something is wrong with the flyweight Sep 16 03:15:49 if the app's open, and you open all the stuff the app can do... i.e. messages, lists, timeline, favorites, retweets, etc.... so they've all been rendered -- Sep 16 03:16:08 the app keeps that stuff open, and user has option to X out of them. but it keeps dom nodes. Sep 16 03:16:17 i just opened all, and i'm now up to 8K~+ Sep 16 03:16:46 so it's not the list size, it's everything in general, just the sheer volume / scale of the app Sep 16 03:18:50 why would you keep it all open? can't you destroy the content of those panels? Sep 16 03:18:53 the good news is i can go and X out of them, and the nodes drop back down. the bad news, is i don't think webos phones can handle it. Sep 16 03:19:06 i COULD, but that really defeats the purpose of the app Sep 16 03:19:45 if you want to discuss it further, it'll have to be another time. i just noticed it is 5:19, and i still need to start sleeping Sep 16 03:19:58 having them open tells the app to refresh it on autorefresher Sep 16 03:20:03 i'd see if there isn't a way in which you can limit the rendering of non-visible views Sep 16 03:20:28 they don't _render_ because they're display:none; w/ panels.. but they're still IN the HTML Sep 16 03:20:43 (also, it is an interesting topic) Sep 16 03:20:50 they might not be accessable directly in DOM, but that doesn't mean they're not in there Sep 16 03:20:54 lol yes Sep 16 03:21:20 fxspec06: split the objects in a visible object and in a non-visible one. the non-visible one can create the visible one. that way you can maintain the relevant state, but build less html nodes. Sep 16 03:21:21 well, thanks, good chat, sleep well Sep 16 03:21:28 thanks! good luck! Sep 16 03:21:49 i'll ponder this, i actually know the issue now, i think Sep 16 03:21:59 now just have to figure something out Sep 16 03:22:07 later! Sep 16 03:22:10 well, you know you have a lot of nodes, you don't know if you need to get data out of memory :) Sep 16 03:22:19 see you! good luck!! Sep 16 03:22:25 ty Sep 16 23:15:38 madnificent Sep 16 23:24:29 so, i'm like, 99.999999999% sure, i've come up with a strategy that would improve neo performance by ..... Sep 16 23:24:40 * fxspec06 generates random theoretical number Sep 16 23:24:46 400-500% Sep 16 23:27:55 that's not really a random number, but i believe it to be accurate Sep 16 23:28:07 and i'll know very soon if my theory is correct. and i hope it is Sep 16 23:39:30 fxspec06: i'll be off soon again, but what's the theory? Sep 16 23:45:34 k Sep 16 23:45:52 so Sep 16 23:46:18 for refresh of memory: neo launch = 1700 nodes Sep 16 23:46:42 loading 3 main columns full of tweets = 2300 nodes Sep 16 23:47:05 filling more columns with more lists = 4200 nodes Sep 16 23:47:17 opening everything you can in the app at least once = 8200 nodes Sep 16 23:47:59 we know the app runs great first launch, nodes is the problem. so, then, the solution would be to not use so many nodes Sep 16 23:48:18 my answer is to do just that. Sep 16 23:49:09 instead of having everything already in memory.... load each view on the fly, saving everything i need to regenerate each view on the go in a published object. Sep 16 23:49:42 the result will not only yield performance because of the nodes being smaller, and the node count will be way smaller, but it'll also be recreating my kinds on the go as well Sep 16 23:50:17 getting rid of potential errors that could happen from having the same thing open for potentially days, or weeks at a time Sep 16 23:51:12 if i wanted, i could even take it a step further, and have a panels kind with a few items pre-rendered, and be able to swipe between them, rendering adjacent views also on the fly Sep 16 23:51:47 then i could write a function to compress everything i save, because a LOT of bytes are being used for empty object properties, or repeated properties Sep 16 23:52:09 the app would... excuse my french, it would screw. Sep 16 23:52:29 it would screw basically. it's be like running on air in a hurricane Sep 16 23:54:15 or even a step further to not have anything on the fly, but also freeze property for the view that renders the next view on touch drag start. Sep 16 23:54:47 * fxspec06 is done Sep 16 23:55:04 there's a good one for the logs. Sep 17 00:07:56 does that sound completely crazy, or am i right Sep 17 01:04:55 hmm. no opinions. Sep 17 01:09:39 fxspec06: interesting! Sep 17 01:10:01 your current approach touches more on the functional programming side then on the object oriented approach. Sep 17 01:10:26 i'm out again, should've been in bed way sooner. don't really grasp where the time went, but it's gone. tty tomorrow, probably. Sep 17 01:11:46 lol, time Sep 17 01:11:59 * fxspec06 doesn't know what time is. no concept. there's only awake and not awake Sep 17 01:12:26 and yes, gotta be a fart stinker to be able to get it to run smoothly Sep 17 01:12:37 anything can run poorly Sep 17 01:16:58 for varying vtalues of anything, can, run and poorly. Sep 17 01:17:07 s/vtalues/values/ Sep 17 01:17:11 looks like it really is bedtime Sep 17 01:17:13 night! **** ENDING LOGGING AT Mon Sep 17 02:59:59 2012