Opera Mobile, offline web app development, and memory

Question

I'm developing a data collection app for use on a HP iPAQ 211 running Windows Mobile 6. I'm doing it as an offline web app (go with what you know) using Opera Mobile 9.7 and Google Gears. Being it is an offline app, it is very dependent on Javascript for much of its behavior. I'm using the LocalServer, Database, and Geolocation components of Gears, as well as the JQuery core and a couple of plugins for form validation and other usability tweaks (no jQuery UI). I've tried to be conservative with my programming style and free up or close resources whenever possible, but Opera just slowly dies after about 10-20 minutes of use. The Javascript engine stops responding, pages only half-load, and eventually stop loading completely. I'm guessing it's a resource issue.

Quitting and relaunching the browser solves the problem, but only temporarily. The iPAQ ships with 128 MB of RAM, about 85-87 MB of which is available immediately after a reset. With only Opera running, there still remains about 50 MB that is left unused.

My questions are thus:

1. Is it possible to get Opera to address this unused RAM? I learned that Windows Mobile 6 has a 32 MB per-process limit, so no.
2. Are there configuration settings in Opera or in the Windows Registry itself that will help improve performance? I know where to tweak, but the descriptions of the opera:config variables that I've found are less than helpful.
3. Is is laughable to ask about memory management and jQuery in the same sentence? If not, does anyone have any suggestions?
4. Finally, are my plans too ambitious, given the platform I have to work with? I know that Gears and Windows Mobile 6 are on their way out, but they (theoretically) suffice for what I need to do. I could ditch them in favor of an iPhone/iPod Touch, Mobile Safari, and HTML5 but I'd like to try to make this work first. I didn't think that Opera was a dog when it comes to JS performance, but perhaps it's worse than I thought.

That this motley collection of technologies works at all is a minor miracle, but it needs to be faster and more stable. I appreciate any suggestions.

Answer 1

is this a persistent JavaScript app, or do you refresh the whole page from time to time?

In the first case, you probably have a memory leak. you should try to isolate it. it may be your fault or coming from one of the libraries you use. when you know, you can decide what to do. or, you could simply do a page refresh every now and then.

In the latter case, you should just drop the project. If a browser just stops working over time, although you give it the explicit chance to free memory, then it's crap.

Answer 2

It sure sounds like something is leaking memory, and I'm afraid the Opera Mobile/Gears combination has not gone through a lot of testing as far as I know. Hence my initial guess would be that the memory leak lies in the Opera/Gears interaction.

(As you might know, since Opera core is cross-platform, Opera's core JS/DOM support should be relatively stable and the "Futhark" ES engine in 9.7 is several years old so pretty well tested and stable..)

I don't know how practical a suggestion this is - but would it be possible for your scenario to minimise the usage of Gears or try to isolate specific features of the Gears interaction that cause problems? For example, if you write a small page using, say, GeoLocation a lot - will it show similar symptoms?

You've probably written a fair amount of code by now though :-/

I'm actually not on top of what exactly is supported on the Widget side in Opera Mobile 9.7, but there might be some features from Widgets (like fileIO) that you might be able to use to replace Gears features and do offline stuff.

Answer 3

For anyone who may come across this later looking for answers to the same problems, just get yourself an iPhone/iPod Touch and develop in Mobile Safari instead. That's what I ended up doing (using persistence.js as an ORM for the SQLite DB). It is truly the superior environment to develop for, at least for the time being.