I'm currently working on a web app, and have been inspired by a couple different apps out there (mainly Cloud9IDE) in how they hold a large majority of their interface in javascript objects. This makes it incredibly easy to add features in the future, and also allows extensibility options in the future.
The question is, at what point does storing data in memory (via javascript) become rude. I'm building a social network (think like Twitter), and essentially I would be storing an object for every "tweet", as well as some more broad objects for interface items.
Are there hard limits forced by browsers on how much memory I can use? Will my website crash if I go over? Or will the entire browser crash? Will it slow down the user? If so, is there a general rule for how much memory will bother the average user?
Absolutely positively don't use anywhere close to 4 GB of memory. Most people use 32-bit browsers, so the browser couldn't support 4 GB anyway :)
On a more practical note, remember that the more memory you take up, the slower your app will usually run. Today's Intel/AMD (I don't know about ARM) processors access registers about 100 times faster than accessing memory that isn't in cache, so if you use a lot of memory you will cause thrashing, which will slow down your application dramatically.
So, assuming that you want users for your social network, you should try to design your website to work well on as many machines as possible. Millions and millions of people are still using Windows XP machines that are 5+ years old. These machines might have as little as 512 MB of RAM, so if you are using a few hundred megabytes, you can thrash all of memory rather than just processor cache, as the kernel keeps swapping out pages that you want to use. So as a rule of thumb I would recommend staying below 150-200 MB of memory. GMail takes up ~100MB of memory on Chrome for Linux, so I think that keeping up with GMail is a reasonable goal.
Another benefit of keeping memory usage relatively low is that your users can more easily view your site on a smartphone. An iPhone 3GS (there are still a lot of them in use) has only 256 MB of RAM, so staying below 200 MB in your website makes it easier for a smartphone user to load your site without having to kill processes indiscriminately.
Related
I'm debugging my javascript web application consisting of a package of ~24MB of images & sounds. I'm not particularly generating a lot of data in my app so the memory usage shouldn't be any higher than 100MB at most.
When checking memory using the chrome profiler, a heap snapshot reports 30MB of usage. Looking at various numbers also reports much the same numbers.
My problem is when looking at memory reports in the Chrome Task Manager, it says the tab is using between 400-600 MB of private bytes of memory. When looking at chrome://memory-internals/ , the report is 400 MB of private bytes and 24 MB in 'V8 Used / Alloc' memory. I'm guessing that the private bytes is the memory used by the JS runtime and V8 the memory of my application.
Now, my question is how can I reduce the memory footprint of the JS runtime ? I'm trying to make my app compatible on mobile and iOS is shutting my app down when loading because I'm using too much RAM. I understand the problem might entirely be on my shoulders but I'm looking for common causes of such a high memory impact on the runtime side of things.
tl;dr: My issue was caused by an extension.
I had somewhat similar problems with one of my applications using around 150MB of RAM, while it should've been way smaller. (The entire folder it was run from was 1.85MB and although a WebSocket connection was kept open, no data was being transferred and no fancy XHR things were happening in the background, which could be explained by this bug.)
After looking around for quite a bit of time I started to get frustrated, because I couldn't figure out where that usage was coming from. I enabled the "JavaScript memory" column in the Chrome Task Manager, recorded timelines, checked heap profiles and all these to no avail. Every source that was able to measure JavaScript's memory usage has shown me around 20MB, but the built in task manager of Windows and Chrome's task manager agreed that the entire tab started using around 30MB of memory after a refresh and slowly climbed up to around 150MB.
Suddenly I had an idea to think about my extensions, and I have realized that I had livepage running on that tab. As soon as I disabled it this anomaly went away, so I would recommend checking their extensions for anybody experiencing chrome memory issues!
My site crashes in the browser due to low memory on iOS. I'm repeating some action which consumes memory. After several attempts, the browser crashes. However, when I tested the same site on my desktop using Chrome by using timelime from dev tools:
Perform the same action
Collect garbage
All additionally allocated memory is collected.
Why does the browser crash if there are no memory leaks? Is there a way to force garbage collection?
Know iOS Resource Limits
Your webpage performing well on the desktop is no guarantee that it will perform well on iOS.
1.Keep in mind that iOS uses
EDGE (lower bandwidth, higher latency)
3G (higher bandwidth, higher latency)
Wi-Fi (higher bandwidth, lower latency)
to connect to the Internet.
2.You need to minimize the size of your webpage.
Including
unused or unnecessary images
CSS
JavaScript
which adversely affects your site’s performance on iOS.
3.Because of the memory available on iOS, there are limits on the number of resources it can process:
The maximum size for decoded GIF, PNG, and TIFF images
3 megapixels for devices with less than 256 MB RAM
5 megapixels for devices with greater or equal than 256 MB RAM
That is ensure width * height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM
Note: that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32 megapixels using
subsampling. JPEG images can be up to 32 megapixels due to
subsampling, which allows JPEG images to decode to a size that has one
sixteenth the number of pixels. JPEG images larger than 2 megapixels
are subsampled—that is, decoded to a reduced size. JPEG subsampling
allows the user to view images from the latest digital cameras.
4.The maximum size for a canvas element is
3 megapixels for devices with less than 256 MB RAM
5 megapixels for devices with greater or equal than 256 MB RAM.
The height and width of a canvas object is 150 x 300 pixels if not specified.
5.JavaScript execution time
limited to 10 seconds for each top-level entry point. If your script
executes for more than 10 seconds, Safari on iOS stops executing the
script at a random place in your code, so unintended consequences
may result.
6.The maximum number of documents that can be open at once is
eight on iPhone
nine on iPad.
Please refer Developing Web Content for Safari-Apple Documentation for more info.
Garbage Collection
Mobile safari javascript implementation doesn't have any command like CollectGarbage() in internet explorer for garbage collection.
There are three events that will trigger garbage collection in
mobile safari(Reference).
A dedicated garbage collection timer expires
An allocation occurs when all of a heap's CollectorBlocks are full.
An object with sufficiently large associated storage is allocated.
Its really a bad practice to trigger garbage collection.What we should be doing is to write codes that doesn't leak memory.
Plese refer Memory management in Javascript
Below is the best resource (with benchmarks) which I have ever come across, that explains it:
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
I hit those performance hurdles a few weeks back, and please note that iOS does not have any default garbage collection (the article explains why). It is the responsibility of the app (in this case, the browser app). You cannot collect garbage via your web app. A small tip while optimizing your website for iOS (to prevent crashes): avoid CSS transations.
Though I would recommend that you grab a cup of coffee and read the complete article, but I'll paste the summary below:
Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).
It’s slower than native code by about 5
It’s comparable to IE8
It’s slower than x86 C/C++ by about 50
It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there
The most viable path for it to get faster is by pushing the hardware to desktop-level performance. This might be viable long-term, but it’s looking like a pretty long wait.
The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code
Garbage collection is exponentially bad in a memory-constrained environment. It is way, way worse than it is in desktop-class or server-class environments.
Every competent mobile developer, whether they use a GCed environment or not, spends a great deal of time thinking about the memory performance of the target device
JavaScript, as it currently exists, is fundamentally opposed to even allowing developers to think about the memory performance of the target device
If they did change their minds and allowed developers to think about memory, experience suggests this is a technically hard problem.
i am stuck with big problem i working on big project that is hanging browser automaticaly javacript executes
"how to detect how much memory javascript is using and clear the memory in regular interval.Is it posible?"
You don't have any way to play with memory. Javascript runs in a sandbox environment, so you have no access to memory management in any way. The garbage collector takes care of this, and you can somehow make it do what you want, but it's random. Don't count on it.
Rather, for your problem, you can use Chrome Inspector's Profiler.
What does it do? Well... it profiles the webpage you're in. You can see how long each function takes, and especially: where is your bottleneck.
Try in Chrome, specifically.
Chrome's V8 has a brilliant generational garbage collector, where three types of polling happens: There are three threads constantly polling the three generation types, and I think they run at 10, 50 and 200 millisecond intervals (I may have got the figures wrong, but they are principally similar, with the time intervals increasing for older generations).
This is aggressive, and ensures that memory usage remains low.
In spite of this, if your code is hogging memory in Chrome, then you can be sure that the issue is with the code. It could be that:
(a) Your code is really unoptimized, or
(b) It is really working on very large data that is probably not best suited for the client (e.g. an excessively heavy page that has tons of widgets, dom nodes etc.)
Care to post some snippets?
I've asked question about JavaScript memory and HTML5 LocalStorage limitations on smartphones, however the problem became a bit more specific.
I need to store for offline usage a lot more data, big part of it are dictionaries. I had an idea to store dictionaries in JavaScript (which loads simply array data into JS variable) which will be cached for offline usage. Business data for offline will be stored in LocalStorage. Additionally JS memory will hold some cache for online usage, to prevent loading same entity more than one time from server.
So I have question, if using big offline cache (say 4MB) and storing a lot in memory affects the storage available for LocalStorage? Say it can become limited to 3MB because of heavy offline cache usage. Does someone has experience with such applications and had to deal with problems with particular browsers on mobile devices?
The answer to similar to mine question Application Cache Manifest + Local Storage Size Limit does not provide the information I need since as fair as I understood the author has tested offline cache limit and LocalStorage limit separately.
Even more I'm worried about JS memory applications, I fear the browser can be closed without even warning. Testing on one device would not mean the application would not crash on another, less powerfull.
So please write, if you have tested the limits of mobile browsers. Post which only give clues where to search further or describe test scenarios which hasn't finished with effort will also be appreciated. The topic is quite new so I'm aware most of researches are drafts only.
update
I've updated my referred question about LocalStorage limitations, with test on Opera Mobile 11, in which I was able to store much above 5MB limit.
Also according to the post Increase iPad cache over 50 MB? at least on iPad it is possible to store 50MB of data, hope I would do test on iPhone soon.
In almost all cases, mobile devices have a hard, 5meg limit for all storage for a domain. That includes all of the local/session storage, indexed db, websql, application cache or anything else.
The best way to store data in this case is either to use local storage or WebSQL for your dictionary data, but instead of storing all of the data, store the 80% use case content, and provide an easy way to be able to load the additional information as necessary.
HTH,
PEte
After experimenting a bit, I've found out that Opera is not limiting the resources. It asks to increase LocalStorage limit, and this limit is not affected by storing files in application cache.
Firefox has configurable LocalStorage limit so in theory it is possible to store large amount of data there, also unaffected by application cache. However, Mobile Firefox is so badly written as its desktop brother and it manages resources so ineffectively that it is killed by Android when the storage is in intensive use. So I would discourage people to use Firefox, at least on Android devices.
Android Browser, on the other way, seems to have 2,5 MB limit, which is unaffected by application cache, however it is lower as it should be, according to suspitions that you have at least 5MB for use. However, this browser also fail to provide accurate GPS location (which is, AFAIK, feature not bug - security reasons), so for me this browser is no option to support.
We are currently trying to optimize page load times on an memory and cpu constrained windows mobile device (the MC9090, 624mhz cpu, 64meg ram, running WinMo 6 and Opera Mobile 9.5). As one of the potential optimiztions, I wanted to combine external js/css files, but now we are observing that page load times actually INCREASE after concatenation.
Now, that flies in the face of everything I have seen and read about with regards to client side performance. Has anyone ever seen this before? Also, are there different rules for embedded device web optimization then desktop browsers?
Browsers can download across multiple connections (4, sometimes 6 - not sure what this version of Opera allows). By putting everything in one file it forces the browser to download all the javascript in one stream, vs. multiple ones. This could be slowing it down.
Images and other items also compete for these connections. You nelly need a tool similar to Firebug's "net" tab to view the traffic and see how the bandwidth resources are allocated.
Also, see: http://loadimpact.com/pageanalyzer.php
out of date but relevant: http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/