Investigate gaps in loading times

[darkf]

Chrome timeline: http://i.imgur.com/kEoi1qF.png

From 2000ms to 5500ms it's not really doing much but scripting; almost no network requests are being made either.

It's not yet in the map loading phase, so I wonder what's going on and why it's not being very productive.

[ori-sky]

The time gap is being caused by the call to m.parseJSON, as this is the entire imagemap that is being parsed. When there's a time gap, the best place to see where the code is spending its time is the call stack view. Even if the bottleneck is network requests, this will be reflected in the call stack. For example, the time gap before heart is initialized is due to its call stack originating with window.load, so the bottleneck there is the initial requests that are performed when the page is loaded.

[darkf]

So it looks like we either want to migrate imageMap to a binary format (like BSON or msgpack), or store it directly in IndexedDB and read it on load (which might be a better idea, then it's only requested once and cached on the client side in a fast store).

[ori-sky]

Either way, I think there's a potential for this to take a long time, as it takes a longer on your machine than for me. On a less powerful machine than yours, it could take even longer, so as such, it may be helpful to have some sort of visual indicator that something is happening, instead of the blank screen that it has currently, while parsing the image map. Even if IndexedDB is used and this indicator is only shown once, it may still be worthwhile.

[darkf]

You have a point.

I looked into IndexedDB implementation performance for this. It looks like Chrome/WebKit and I believe Firefox also store IDB values as binary blobs in SQLite, so it should be fast (some erroneous SO answers claim they basically get JSON serialized, which is not correct). It would entirely skip the parsing of JSON each time, and the get should be quick.

It's still worth binary serializing the JSON (and perhaps others), but IMO only if we also use the binary serialization library for something else as well.

In any case, an IDB cache store should be implemented which transparently loads imageMap (and possibly others) from cache or the network.

[darkf]

Implemented the IDB cache in the idbcache branch. It shaved off ~7s of JSON processing on my machine, but the load latency still hasn't gone down a whole lot (if any).

Going to relate this to #92 since it could tag along with this.

[darkf]

Did #92 in the same branch. It cuts down on requests and should have been loading time too, but it still takes ~10s to fully load the starting map on my machine. There are still improvements to be made like requesting them concurrently (allowing the browser to pipeline them), but I really expected some reductions here.