4 ms·

Over time, NewTwitter does incur a large memory footprint. I've been traveling for a month and haven't looked into the problem in depth, but I'd bet the major c

by russ 16y ago

Over time, NewTwitter does incur a large memory footprint. I've been traveling for a month and haven't looked into the problem in depth, but I'd bet the major culprit is our aggressive caching techniques. It's also worth investigating the number of polls and their frequencies. Timeline refreshes are dropped back to 90 seconds when the tab isn't focused, but not sure about other ones. As most people have reported, infinite scroll is an easy way to introduce a slowdown over time. The sheer number of DOM nodes becomes quite significant - there are things we can do to ameliorate that issue, as well. Will take a look tomorrow. The feedback is greatly appreciated.

kragen 16y ago
It also doesn't work in the version of Arora I have. I imagine it will suck as much as Facebook does on the Kindle browser. Is there a version of Twitter that will work in a plain HTML browser with cookies and no JS? Please?
- russ 16y ago
  Try http://mobile.twitter.com http://mobile.twitter.com
  - 1337p337 16y ago
    As much as I love the minimal UI, the mobile version is crippled by comparison. If they flesh out the features (which can be done without bloating it) or they deprecate the old UI like they're threatening, then I'll use it constantly. The old UI works great and does not monopolize CPU, unlike the new one which, on load, eats 100% of one core on whatever machine I'm using (to say nothing of the really wide horizontal resolution required).
  - kragen 16y ago
    Yeah, I've been using it today. I want to love it but I can't. No DM count on the screen (to save three bytes?!), no user icons, no way to tell that I've gone over 140 characters.
    - sandofsky 16y ago
      Are you using a really low end user agent to try to access the site? I don't know what's turned off for lower end browsers, but I just tested in desktop Webkit. There's a character count in the upper right of the tweet box. There are user icons, unless you clicked the "images off" link. As for total DM count, that isn't really possible right now. The app is just another API client, and the DM API endpoint only provides the last 20 DMs.
      - kragen 16y ago
        No, FF3.
        wahnfrieden 16y ago
        Just a tip -- relaunch FF in safe mode (sans extensions etc.) and verify before reporting bugs like that, please.
  - mike-cardwell 16y ago
    Trouble with the mobile version is it doesn't support https for some reason and so can't be used safely on an untrusted network. The normal version supports https though...
russ 16y ago
Update: Apparently there was a regression introduced last week that has exacerbated this problem. Some folks are working on a fix.
catshirt 16y ago
With respect, why exactly is total script size 912kb minified? That seems unexpectedly high. Likely not the root of the problem at hand, just curious. Also interested in what you plan to do to alleviate massive DOM issues, if you could share. Typically an overlooked point of performance.
- russ 16y ago
  I don't have a breakdown with precise numbers for you, but some bloat comes from the fact that we include all of our templates in the phoenix bundle. Some savings could come from fetching certain components and pages on demand, but right now, we pull down everything. Gzipped it drops to ~200k, which isn't terrible considering that this is fetched in parallel with API resources and the initialization of our cross-domain iFrame. We're currently working on getting our bootstrap time down, so the bundle size may be reduced as a result of that effort. Re: DOM issues, when you switch around between pages and/or timelines, we detach the timeline DOM elements and keep a reference in memory. Upon returning to a previously loaded timeline, we do a repaint (not bad). Right now, we don't employ any such technique for an active timeline that has been scrolled a long way down. One thing we can do is detach large blocks of tweets that aren't in the viewport and splice them back in (while maintaining an accurate scroll height) if the user scrolls back up.
  - catshirt 16y ago
    Good deal russ, thanks. There's a fine balance to maintain between combining and lazy loading files. Still seems to be one of the harder front end problems to solve since client side architectures are all relatively unique. Thanks again sir.
saurik 16y ago
Infinite scroll is also a way to make scrolling infuriating, especially if you are wanting to click links and fan out from that location: it forces you to avoid your browser's carefully designed history stack like the plague (opening new tabs or windows for navigation instead) lest you lose your incredibly valuable document you've carefully been scrolling down in (and which is now so large it is threatening to cripple your browser anyway). What happened to normal "next page" paradigms? Does user testing really show that infinite scroll is better?
- wahnfrieden 16y ago
  That's not a problem inherent to infinite scroll at all. It's easily fixed by setting a hash value on the current page (the #foo in a URL) corresponding to the current scroll state, and updating it each time infinite scroll happens. Why Twitter doesn't implement something like this is a whole different issue.
  - russ 16y ago
    You can imagine attempting to support something like this when the user has scrolled 20 pages worth through a timeline. We could, of course, backfill newer tweets subsequently up to the most recent (taking a minimum of two requests and a maximum of 20), but this would be expensive. I mentioned somewhere else in this thread that we could maintain an accurate scroll height but detach more recent tweets when a timeline is scrolled a long distance. We could do the same thing here, and backfill as the user scrolls up. There are some challenging things to get right though if the user decides to jump to the top, etc. Definitely non-trivial.
    - wahnfrieden 16y ago
      Thanks for the response, I thought the reality would be much more complicated due to issues of scale. This is primarily about supporting the back button, and I don't think users expect the latest data when going back through their browser history - generally pages aren't refreshed, and that's not an unusual or unexpected behavior. So you could cache each page state, without worrying about displaying newer tweets, though the caching mechanism itself incurs some nontrivial cost.

by russ 16y ago

kragen 16y ago

It also doesn't work in the version of Arora I have. I imagine it will suck as much as Facebook does on the Kindle browser. Is there a version of Twitter that will work in a plain HTML browser with cookies and no JS? Please?

russ 16y ago
Try http://mobile.twitter.com http://mobile.twitter.com
- 1337p337 16y ago
  As much as I love the minimal UI, the mobile version is crippled by comparison. If they flesh out the features (which can be done without bloating it) or they deprecate the old UI like they're threatening, then I'll use it constantly. The old UI works great and does not monopolize CPU, unlike the new one which, on load, eats 100% of one core on whatever machine I'm using (to say nothing of the really wide horizontal resolution required).
- kragen 16y ago
  Yeah, I've been using it today. I want to love it but I can't. No DM count on the screen (to save three bytes?!), no user icons, no way to tell that I've gone over 140 characters.
  - sandofsky 16y ago
    Are you using a really low end user agent to try to access the site? I don't know what's turned off for lower end browsers, but I just tested in desktop Webkit. There's a character count in the upper right of the tweet box. There are user icons, unless you clicked the "images off" link. As for total DM count, that isn't really possible right now. The app is just another API client, and the DM API endpoint only provides the last 20 DMs.
    - kragen 16y ago
      No, FF3.
      - wahnfrieden 16y ago
        Just a tip -- relaunch FF in safe mode (sans extensions etc.) and verify before reporting bugs like that, please.
- mike-cardwell 16y ago
  Trouble with the mobile version is it doesn't support https for some reason and so can't be used safely on an untrusted network. The normal version supports https though...

russ 16y ago

Update: Apparently there was a regression introduced last week that has exacerbated this problem. Some folks are working on a fix.

catshirt 16y ago

With respect, why exactly is total script size 912kb minified? That seems unexpectedly high. Likely not the root of the problem at hand, just curious. Also interested in what you plan to do to alleviate massive DOM issues, if you could share. Typically an overlooked point of performance.

russ 16y ago
I don't have a breakdown with precise numbers for you, but some bloat comes from the fact that we include all of our templates in the phoenix bundle. Some savings could come from fetching certain components and pages on demand, but right now, we pull down everything. Gzipped it drops to ~200k, which isn't terrible considering that this is fetched in parallel with API resources and the initialization of our cross-domain iFrame. We're currently working on getting our bootstrap time down, so the bundle size may be reduced as a result of that effort. Re: DOM issues, when you switch around between pages and/or timelines, we detach the timeline DOM elements and keep a reference in memory. Upon returning to a previously loaded timeline, we do a repaint (not bad). Right now, we don't employ any such technique for an active timeline that has been scrolled a long way down. One thing we can do is detach large blocks of tweets that aren't in the viewport and splice them back in (while maintaining an accurate scroll height) if the user scrolls back up.
- catshirt 16y ago
  Good deal russ, thanks. There's a fine balance to maintain between combining and lazy loading files. Still seems to be one of the harder front end problems to solve since client side architectures are all relatively unique. Thanks again sir.

saurik 16y ago

Infinite scroll is also a way to make scrolling infuriating, especially if you are wanting to click links and fan out from that location: it forces you to avoid your browser's carefully designed history stack like the plague (opening new tabs or windows for navigation instead) lest you lose your incredibly valuable document you've carefully been scrolling down in (and which is now so large it is threatening to cripple your browser anyway). What happened to normal "next page" paradigms? Does user testing really show that infinite scroll is better?

wahnfrieden 16y ago
That's not a problem inherent to infinite scroll at all. It's easily fixed by setting a hash value on the current page (the #foo in a URL) corresponding to the current scroll state, and updating it each time infinite scroll happens. Why Twitter doesn't implement something like this is a whole different issue.
- russ 16y ago
  You can imagine attempting to support something like this when the user has scrolled 20 pages worth through a timeline. We could, of course, backfill newer tweets subsequently up to the most recent (taking a minimum of two requests and a maximum of 20), but this would be expensive. I mentioned somewhere else in this thread that we could maintain an accurate scroll height but detach more recent tweets when a timeline is scrolled a long distance. We could do the same thing here, and backfill as the user scrolls up. There are some challenging things to get right though if the user decides to jump to the top, etc. Definitely non-trivial.
  - wahnfrieden 16y ago
    Thanks for the response, I thought the reality would be much more complicated due to issues of scale. This is primarily about supporting the back button, and I don't think users expect the latest data when going back through their browser history - generally pages aren't refreshed, and that's not an unusual or unexpected behavior. So you could cache each page state, without worrying about displaying newer tweets, though the caching mechanism itself incurs some nontrivial cost.