JavaScript constructs/patterns to avoid on iOS Safari?

Question

I have a web app that contains a huge amount of generated JavaScript. The memory consumption differs by a factor 6 between running the web app in Chrome on a Desktop compared to running the web app in a UIWebView on an (updated) iPad.

What constructs or patterns should I avoid to get the memory consumption on iOS on par with that of Chrome?

Characterisation of the generated JavaScript:

The code is generated by Haxe.
The code is "object oriented" in that it makes heavy use of prototype, but in a civilized way.
The code makes heavy use of named indexes on JavaScript objects to implement hash tables.
There are a lot of strings, but hardly any string concatenations.

There does not appear to be any memory leaks; the excessive memory consumption on iOS shows immediately upon construction of the (fixed set of) Javascript objects.

Note that UIWebView uses an older Javascript engine, it executes JS slower than Safari on iOS. If you run the code in Safari, does that run fast enough? — Mark Knol, Aug 19 '15 at 19:44
The web app is supposed to be run from Safari, I only use UIWebView to allow XCode to see the memory consumption, which is what is the problem (ie. Safari reloads the page now and then). The execution speed is not really a problem. — jpsecher, Aug 20 '15 at 06:39
Mobile safari uses WKWebView so your app should instantiate one of those instead to do the comparison. You may also want to add `v8` and `javascriptcore` to the tags so experts in those two JS engines can weigh in. — Ed Ballot, Aug 28 '15 at 01:12
Have you tried to open an issue on the dedicated github? https://github.com/HaxeFoundation/haxe/issues — lifeisfoo, Sep 01 '15 at 12:20
I don't think there are any patterns to apply to work around a flawed implementation. It might just need more memory than V8. — Bergi, Sep 02 '15 at 16:34
If you use NSURLRequest, according to the following answer you will want to play with the cache policy to get more representative numbers. http://stackoverflow.com/a/22940315/3802077 — user3802077, Sep 08 '15 at 03:55
If you haven't any memory leaks as you said, than there is not a much what you can do here though. Im not very familiar with haxe, but looks like there are the root of your huge memory. Is it possible to see where are the junk of the memory coming from? — Eduard Jacko, Nov 04 '15 at 09:24

Niels · Answer 1 · 2016-01-30T19:44:32.620

Since your code does run well on the desktop it is probably some underlying quirk in iOS. Which I doubt you can fix using a more object oriented way of programming. Sure this might reduce the memory footprint a bit but not by a factor of 6.

UIWebView is quite notorious for creating memory leaks you could try to use the newer (iOS 8+) WKWebView has much better garbage collection.

Apple WKWebView Reference

score 1 · Answer 2 · answered Jan 28 '16 at 08:31

My Suggestion is that you look into the DOM part of your application. I don't think there is much optimization that can be done in your JavaScript structure. The weak link in mobile/tablets is usually the rendering process. If your goal is to reduce memory consumption, you can change the way your DOM works. try to to keep as minimum DOM nodes as you can, hide content (node-content) of of hidden DOM nodes. this kind of DOM manipulations , helped me in the past to make my web app more responsive , and to keep memory usage as low as possible .

Virtual Scroll , is something useful for keeping the dom as small as possible , virtual-scroll

score -1 · Answer 3 · answered Sep 21 '15 at 11:23

A potential way you can try optimizing your code is via GWT (whose compiler, i believe, is a more optimizing compiler than haxe's js compiler).

I would first compile all your haxe code into java, then convert that into js via GWT,and see if the memory requirements remain similarly high.

If converting to java, then to GWT is too difficult, a close approximation is to use the google closure compiler on the resultant javascript generated via haxe. I m not sure if haxe is capable of outputting javascript in a way that is compatible with the ADVANCED_OPTIMIZATION mode (https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations), which is what you'd need to do (otherwise, closure is no better than a simple code minimizer).

score -2 · Answer 4 · answered Oct 06 '15 at 12:01

You mentioned it is using heavily of prototype. That could be a reason: if you think your objects can share same prototype try to do so; For Example:

baz.Bar = function () {
    // constructor
};

baz.Bar.prototype = {
    fooProp: ["bar", "foo"],
    foo : function (){
        //method
    }
};

baz.Bar2.prototype = baz.Bar.prototype;

You will notice baz.Bar2.prototype is pointing to baz.Bar.prototype. With this concept, you can save the memory to be allocated by baz.Bar2 because it sharing from baz.Bar.

JavaScript constructs/patterns to avoid on iOS Safari?

4 Answers4