Loader optimization necessary?

[rinogo]

Hey all!

Long story short - I'm dynamically loading many (40) images with Loader. In most scenarios, many of those images are duplicates (e.g. we're only loading 20 unique images, and the others are duplicates).

My Loader code is pretty standard:

trace('Loading ' + filename);
loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.INIT, initListener);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, ioErrorListener);
loader.load(new URLRequest(filename));

First question:
My assumption is that if I load the same image multiple times, it is only transferred over HTTP once after which each Loader just loads its own copy from the cache. Is this assumption correct?

Second/third questions:
How much overhead is introduced with these 'browser-level' cache hits? (Since the browser manages HTTP transfers/caching/etc). I could theoretically write my own LoaderManager class that would only user Loader once per image, and then subsequent requests for duplicate images would directly return a reference to loader.content. (In other words, instead of hitting the browser cache, I would simply write my own internal cache and hit it instead).

Is it worth the effort to write this application-level cache, or do you think the benefits will be negligible? (Writing this manager class will take two hours or so, and I'd rather avoid wasting that time if it won't be worth it)

What do you think?

[senocular]

It would help in both load performance and memory if you cached and reused existing items, but its not necessary if you're not feeling any negative impact from loading from the cache as is

[rinogo]

Thanks for the response as always, senocular! That's just the thing - I load all of the images at the same time, and I am experiencing a speed hit. Maybe I'll just code up the changes and see if it helps... :/

[rinogo]

Done with the quick 'n dirty version of the implementation. Didn't seem to help much. Maybe the speed hit is in creating the DisplayObjects used to display the bitmaps... Or could it be something else?

[shawnblais]

You'll see a hit just from trying to instanciate that many load operations at once.

The best approach is to probably implement some sort of queue system, where you have say 5 - 10 active downloads at any given time, and as one finished the next one starts.

Or the easier way, just set up a timer and space your loads out by like .1 seconds...

[senocular]

The standard limitation is 4 open connections at once

[shawnblais]

Originally Posted by senocular

The standard limitation is 4 open connections at once

What do you mean "standard"?? Is that the max concurrent connections that are actually made??

[senocular]

Actually that data might be outdated. Seems now both FF and IE use 6, but limit 2 per domain? It all depends on the client.

[rinogo]

For what it's worth:

Seems like I was just stressing the interpreter a bit too much (initializing my app, starting tweens, loading images, etc all at the same time).

The cached Loader class works like a charm but doesn't really boost responsiveness (although surely it reduces the memory footprint and is 'cleaner') - I don't regret implementing it.

What *did* end up helping was adding a trivial delay to some of the initialization. Namely, 'cycler.show(0)' is the command that 'starts' the app, including displaying lots of Sprites, tweening them, etc. Delaying this command by 10ms helped immensely:

setTimeout(cycler.show, 10, 0)

Funny how such a trivial delay (10ms) could have such a significant effect on app responsiveness...

Anyway, there you go. Thanks for the help, guys.

[shawnblais]

Originally Posted by senocular

Actually that data might be outdated. Seems now both FF and IE use 6, but limit 2 per domain? It all depends on the client.

Ahh cool, thanks for the info