14 ms·

JQuery Upgrade Causing Trouble for Twitter?

20 points by atularora 16y ago

leppie 16y ago
I wonder if this (jQuery, not Twitter) is the cause of extreme memory usage in the latest stable Chrome. I get into work in the mornings and some tabs are using more than 500MB memory, other tabs are between 100MB and 200MB.
- jrockway 16y ago
  What does "using" mean? Virtual memory? Resident memory? Shared memory?
  - leppie 16y ago
    'Private bytes' as reported by Process Explorer.
- jeresig 16y ago
  I'm not sure why you would think that? The issue described in this blog post is relating to the performance of a particular CSS selector that jQuery implements - not really anything having to do with memory usage (and the memory usage of jQuery certainly isn't anything significantly above-and-beyond what a normal web application would use).
  - leppie 16y ago
    I was just wondering :) I am probably completely off target. Here is a screenie of what I get every morning. Chrome 9 now (same for 8). 1st col is pvt bytes, 2nd is working set: http://imageupload.org/?di=13129549812715 http://imageupload.org/?di=13129549812715 Edit: Interestingly after some usage, the memory gets freed, and it seems to return to normal again, ~50MB per tab. Edit 2: Now I seem to get some Flash not responding dialogs. Sorry, it seems more likely a Flash issue, although I dont even have any Flash open on any tab. Edit 3: Chrome stats: http://imageupload.org/?di=212954996318 http://imageupload.org/?di=212954996318. Seems there is a problem with GC being a 'tad' conservative.
bsiemon 16y ago
Look out for the bus!
code_duck 16y ago
Oh no, don't let David Mark hear about this one. I've had issues with jQuery upgrades causing problems in the past. Changing jQuery versions has come to be something that I'm wary of, as everything must be carefully tested in each browser. It's more complex than just checking a layout or running your app through each part once, you have to really simulate several user sessions to see if anything feels off.
- riffraff 16y ago
  for reference, David Mark on jQuery http://groups.google.com/group/comp.lang.javascript/msg/37cb11852d7ca75c?hl=en&#38 http://groups.google.com/group/comp.lang.javascript/msg/37cb...;
  - ot 16y ago
    It seems that his (valid) criticisms are about some implementation details (hence fixable without changing the library interface) and the message is almost two years old. Have things improved since then?
    - jeresig 16y ago
      I don't think any of the points that were mentioned in his post are relevant any longer (not that many of the issues that he mentioned were entirely relevant to begin with, mostly just excessive grandstanding over minutia).
  - code_duck 16y ago
    Oh, it goes on from that. He makes bizarre comments about jQuery every chance he gets (strange, immature snipes like "your jQuery is showing"). He's obsessed. I just mentioned what I did because I know it would make him feel so vindicated... he's essentially claimed before that jQuery is the reason for all of the world's JavaScript errors.
- jeresig 16y ago
  At a fundamental level people end up putting jQuery through a huge number of unknown situations (millions of users on even more web sites in even weirder browsers). While we certainly strive to have as few issues pop up as possible they seem to be an inevitability. That being said we aren't satisfied with the number of regressions that currently pop up and have instituted a number of changes into our development process: - Significant core rewrites now only occur during major (1.x) releases. - New features are only added during major releases. - APIs are only added/removed/changed during major releases (unchanged, we've always done this). - Behavior of specific API calls are only changed during major releases. We've also changed our workflow. We're now doing minor (1.x.x) releases roughly every month and major (1.x) releases every three months. Thus we can still get a good flow of good features out in a consistent manner. I should also mention that the jQuery core development team has many more people helping out now. Active participation has always been a challenge for the team (bug triage and fixing isn't very glamorous). We now have about 8 people who are entirely dedicated to bug triage, test case creation, and prioritization. These people work closely with the core dev team (which has recently more than doubled in size). All of this will help to significantly improve the quality of releases (and has done so quite well with 1.4.4 - 1.4.4 was a very good release, better than 1.4.3. I suspect that if Twitter had issues with upgrading from 1.4.2 to 1.4.4 it was because they had issues with 1.4.3).
deleted 16y ago
[deleted]
moses1400 16y ago
This is so much better now in IE it's not even funny - last few weeks the browser has crawled because of Twitter - now it is running smoother tonight.
jeresig 16y ago
Huh - interesting. As far as we know we haven't received any bug reports from the Twitter team (although we have reached out to them - and they do have our contact information) regarding this issue. Additionally I don't think we've received any reports regarding selector performance regressions in 1.4.4. I'd definitely be curious to see what the issue is (and fix it for 1.5) but at least right now there isn't a whole lot for us to do (other than continuing to try and contact Twitter).
hgmichna 16y ago
I'm surprised that Twitter uses jQuery. That doesn't make sense to me at all, since Twitter's site should be a professional, high-performance web site. That's exactly a counter-indication for jQuery, which is suitable only for low-performance web sites made by JavaScript beginners. jQuery is far too poor performance-wise and far too unreliable for any important web site. My guess is that Twitter used jQuery's CSS selector query in a situation where searching for a selector is totally unnecessary and undesirable, because it is much slower than any sensible method to find an element.

20 points by atularora 16y ago

I wonder if this (jQuery, not Twitter) is the cause of extreme memory usage in the latest stable Chrome. I get into work in the mornings and some tabs are using more than 500MB memory, other tabs are between 100MB and 200MB.

jrockway 16y ago
What does "using" mean? Virtual memory? Resident memory? Shared memory?
- leppie 16y ago
  'Private bytes' as reported by Process Explorer.
jeresig 16y ago
I'm not sure why you would think that? The issue described in this blog post is relating to the performance of a particular CSS selector that jQuery implements - not really anything having to do with memory usage (and the memory usage of jQuery certainly isn't anything significantly above-and-beyond what a normal web application would use).
- leppie 16y ago
  I was just wondering :) I am probably completely off target. Here is a screenie of what I get every morning. Chrome 9 now (same for 8). 1st col is pvt bytes, 2nd is working set: http://imageupload.org/?di=13129549812715 http://imageupload.org/?di=13129549812715 Edit: Interestingly after some usage, the memory gets freed, and it seems to return to normal again, ~50MB per tab. Edit 2: Now I seem to get some Flash not responding dialogs. Sorry, it seems more likely a Flash issue, although I dont even have any Flash open on any tab. Edit 3: Chrome stats: http://imageupload.org/?di=212954996318 http://imageupload.org/?di=212954996318. Seems there is a problem with GC being a 'tad' conservative.

bsiemon 16y ago

Look out for the bus!

code_duck 16y ago

Oh no, don't let David Mark hear about this one. I've had issues with jQuery upgrades causing problems in the past. Changing jQuery versions has come to be something that I'm wary of, as everything must be carefully tested in each browser. It's more complex than just checking a layout or running your app through each part once, you have to really simulate several user sessions to see if anything feels off.

riffraff 16y ago
for reference, David Mark on jQuery http://groups.google.com/group/comp.lang.javascript/msg/37cb11852d7ca75c?hl=en&#38 http://groups.google.com/group/comp.lang.javascript/msg/37cb...;
- ot 16y ago
  It seems that his (valid) criticisms are about some implementation details (hence fixable without changing the library interface) and the message is almost two years old. Have things improved since then?
  - jeresig 16y ago
    I don't think any of the points that were mentioned in his post are relevant any longer (not that many of the issues that he mentioned were entirely relevant to begin with, mostly just excessive grandstanding over minutia).
- code_duck 16y ago
  Oh, it goes on from that. He makes bizarre comments about jQuery every chance he gets (strange, immature snipes like "your jQuery is showing"). He's obsessed. I just mentioned what I did because I know it would make him feel so vindicated... he's essentially claimed before that jQuery is the reason for all of the world's JavaScript errors.
jeresig 16y ago
At a fundamental level people end up putting jQuery through a huge number of unknown situations (millions of users on even more web sites in even weirder browsers). While we certainly strive to have as few issues pop up as possible they seem to be an inevitability. That being said we aren't satisfied with the number of regressions that currently pop up and have instituted a number of changes into our development process: - Significant core rewrites now only occur during major (1.x) releases. - New features are only added during major releases. - APIs are only added/removed/changed during major releases (unchanged, we've always done this). - Behavior of specific API calls are only changed during major releases. We've also changed our workflow. We're now doing minor (1.x.x) releases roughly every month and major (1.x) releases every three months. Thus we can still get a good flow of good features out in a consistent manner. I should also mention that the jQuery core development team has many more people helping out now. Active participation has always been a challenge for the team (bug triage and fixing isn't very glamorous). We now have about 8 people who are entirely dedicated to bug triage, test case creation, and prioritization. These people work closely with the core dev team (which has recently more than doubled in size). All of this will help to significantly improve the quality of releases (and has done so quite well with 1.4.4 - 1.4.4 was a very good release, better than 1.4.3. I suspect that if Twitter had issues with upgrading from 1.4.2 to 1.4.4 it was because they had issues with 1.4.3).

deleted 16y ago

[deleted]

moses1400 16y ago

This is so much better now in IE it's not even funny - last few weeks the browser has crawled because of Twitter - now it is running smoother tonight.

jeresig 16y ago

Huh - interesting. As far as we know we haven't received any bug reports from the Twitter team (although we have reached out to them - and they do have our contact information) regarding this issue. Additionally I don't think we've received any reports regarding selector performance regressions in 1.4.4. I'd definitely be curious to see what the issue is (and fix it for 1.5) but at least right now there isn't a whole lot for us to do (other than continuing to try and contact Twitter).

hgmichna 16y ago

I'm surprised that Twitter uses jQuery. That doesn't make sense to me at all, since Twitter's site should be a professional, high-performance web site. That's exactly a counter-indication for jQuery, which is suitable only for low-performance web sites made by JavaScript beginners. jQuery is far too poor performance-wise and far too unreliable for any important web site. My guess is that Twitter used jQuery's CSS selector query in a situation where searching for a selector is totally unnecessary and undesirable, because it is much slower than any sensible method to find an element.