Hacker News new | past | comments | ask | show | jobs | submit login

I know this will probably get downvoted into oblivious but is string space really an issue in the browser?

For example, this page at the time of this post has 68k of html so 68k of text. Let's assume it's all ASCII but we store it at 32bits per character so it's 4x in memory or 270k. Checking Chrome's task manager this page is using 42meg of ram. Do I really care about 68k vs 270k when something else is using 42meg of ram for this page? Firefox is also at a similar level.

Why optimize this? It seems like wrong thing to optimize? Especially for the complexity added to the code.




Browsers and JS VMs are so widely deployed now that anything that can be done to make them faster or use less memory has a tremendous effect in the aggregate. What's really cool is that you can update a browser and suddenly the web starts working better for everyone who uses the browser.

Browser memory usage does tend to creep up unless there is active work to keep it under control. So I think it is important to try and trim the fat where possible. Just look at Are we slim yet? to see Firefox's memory usage slowly growing over time.

https://areweslimyet.com/

By the way, JS engine optimisation does seem like it is getting more and more complicated. I suppose most of the easy optimisations have already been done. Look at Safari adding a fourth layer to its JIT!

https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-...

It's kind of crazy, but totally worth it! (IMO)

The string slimming work in IonMonkey sounds like it got some memory improvements without too much more complexity. Remember the string logic is already complicated—around 6 different string types. The kinds of pages where I think you'd see a real memory improvements would be in JS-heavy pages which store lots of data in memory. These types of pages are becoming more and more common.

I imagine it would also be a big improvement for any software running on Firefox OS. It would be especially noticeable because Firefox OS is targeted at low cost mobile devices.


I'd guess that it's actually quite an issue for JS heavy pages. This would probably benefit anyone doing signification in-browser apps in JS.


Hmmm, checking for example Gmail which is arguably a heavy page it's got 4meg of requests for various js + html files. So 16meg if expanded to 32bits per code point. But it's using 160meg of ram. Strings are not where all the space is going it would seem.


If you actually read the linked article, it has measurements for how much RAM strings use in Gmail. For the particular case of the article's author, it was about 11MB of strings before the changes he made; it was about 6-7MB of strings afterward. Your mileage will vary depending on what actual mails you have, of course.

Note also that comparing this to the Chrome numbers for overall Gmail memory usage is comparing apples and oranges: Firefox tends to use less memory than Chrome. You'd want to look at about:memory in Firefox to see how much memory that gmail page is likely using.


The raw source code is not the only strings in an application. Gmail especially will be heavily manipulating the DOM and a variety of other things (JS properties, JSON requests) which use Strings internally.


Strings using less memory will also speed up string operations as you can see from their 36% win in the regexp-dna benchmark.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: