**** BEGIN LOGGING AT Sat Sep 15 02:59:59 2012 Sep 15 05:58:33 * fxspec06 found a rendering bug in chrome Sep 15 06:00:47 nope, nvm Sep 15 06:01:09 just a personal problem Sep 15 06:38:44 fxspec06, we don't talk about those in polite company... Sep 16 01:39:02 would my app run better if i saved tweets on the device instead of in memory Sep 16 02:45:26 fxspec06: isn't the memory on the device? Sep 16 02:46:52 i should have said, on the drive Sep 16 02:47:19 i'm crawling through my app, backwards, fn by fn. i don't think this is gonna be ready this week, damnit... =\ Sep 16 02:48:29 do you mean: if i store the tweets on the device instead of fetching them through the api each time? i don't really see how storing things on the flash disk is going to help you versus in your own in-memory datastructure. at least, if your internal datastructure makes sense for the way you're accessing the data. Sep 16 02:49:35 no, no. i'm talking about RAM vs storage Sep 16 02:50:05 if you fetch data from storage and you want to use it, it'll be fetched from disk, to ram, to the cpu. so you're just adding overhead. Sep 16 02:51:20 (which could, in theory, still be faster if the data structures on disk would be vastly superior to those in memory, but let's assume you want to get the same objects back) Sep 16 02:51:29 my theory though is that the enyo lists are too big, or the arrays are too big Sep 16 02:51:46 do you store the data in enyo objects? Sep 16 02:51:51 if i limit them myself it could be faster Sep 16 02:51:57 enyo objects.. ? Sep 16 02:52:40 as in, you make an object by writing new my.domain.Tweet(...); Sep 16 02:52:56 no, just large objects/arrays Sep 16 02:53:05 and massive enyo lists Sep 16 02:55:01 arrays tend to be rather good in javascript, at least in the short tests i did about it. Sep 16 02:56:24 yes but there is only so much RAM Sep 16 02:56:27 also, if it wouldn't fit in memory, i think other processes would be swapped out, instead of your application Sep 16 02:56:50 before long the swap would activate, i worry about that, and how that affects performance. that's my main concern Sep 16 02:56:52 so, you should probably check to see if your device is swapping, if so, you may be killing it (and manually managing disk could potentially make it better) Sep 16 02:57:29 but swapping is often still better than storing it on disk and reading it again. the data doesn't need to be parsed again, it's the correct in-memory representation. Sep 16 02:57:37 i'm still trying to optimize app flow, man what a argh Sep 16 02:58:06 i think maybe i could just limit the number of tweets stored in active memory, in addition to limiting the # in localstorage Sep 16 02:58:28 i don't think there's a need to keep 20,000 tweets if you've kept the app open for 3 days Sep 16 02:58:37 first see if you're swapping, if so, fix it. Sep 16 02:59:27 k Sep 16 02:59:29 there's little wrong with fetching tweets if people scroll back further... yes, it'll be an extra request, but it'll be fair for the user to watch. you could even let them decide how many should be available. Sep 16 02:59:45 but i'd profile before i'd start fixing **** ENDING LOGGING AT Sun Sep 16 02:59:59 2012