Comments on: Map Performance

By: jackson

jackson — Sun, 20 Dec 2009 23:35:47 +0000

This is a valid concern. I agree that this would make the results more consistent. However, I see that approach as unfair to the non-Vector data structures. Since try/catch is not required for them, the results would be slower than they need to be. Any knowledgeable programmer would know that a try/catch is not required (an error will never be thrown) and would therefore not use a try/catch. So what I've essentially done in my testing is recognize the extra burden that Vector places on its users: a try/catch. Testing all the other data structures with a try/catch would yield different (but valid!) results that would more accurately show the relative cost of misses. However, my goal is simply different: optimum performance for each data structure. Thanks for pointing out this small-but-important distinction!

By: Dimarik

Dimarik — Sun, 20 Dec 2009 22:06:05 +0000

try…catch is very slow. I think you should wrap all testing items in the “Miss” section to try…catch to get relevant results.

By: jackson

jackson — Sun, 13 Dec 2009 20:43:32 +0000

I assume you mean this article. It was a very interesting read and, from its conclusion that an Array is part dense and part hash, it seems as though my test only covered the faster dense portion. So the performance may be lower for Array if you index beyond the first undefined value. I would say, in the context of this test, that I've tested Array fairly since it would be an avoidable performance mistake to allow undefined values in the Array to cause hash table lookups. Nevertheless, it's good to consider this and I'm glad you pointed it out. I've just started to read your site and find your articles on Tamarin quite interesting. I'm off to read some more!

By: jpauclair

jpauclair — Sun, 13 Dec 2009 15:32:35 +0000

Great article!
But you should read my post about array at jpauclair.wordpress.com
There’s more than one structure in the “Array” and you should do your tests against each.

Thanks!

By: TwoFace

TwoFace — Fri, 27 Nov 2009 14:37:42 +0000

As usual great article, thanks!

By: jackson

jackson — Mon, 23 Nov 2009 18:02:47 +0000

I do too! I think it's a great solution if your key is naturally two integers, such as a row/col pair or x/y pair. Doing some arithmetic (probably a multiply and a divide) to get a 1-D index for a Vector is probably enough to make BitmapData competitive in performance. Plus, the resulting code will probably be clearer and, as you point out, you can display it!

By: jackson

jackson — Mon, 23 Nov 2009 17:58:54 +0000

That part didn't actually matter since the value actually stored in the Vector was irrelevant. The important part was, as Jonathan pointed out, that the test for fixed-size Vector misses was actually hitting and therefore performing far faster than the dynamic-size Vector test, which was (correctly) missing. I've updated the article now with both your fix and his. Thanks for pointing this out!

By: jackson

jackson — Mon, 23 Nov 2009 17:55:49 +0000

Thanks for pointing this out. I’ve updated the article to fix the code and results. It makes much more sense now, too! :)

By: Og2t

Og2t — Mon, 23 Nov 2009 13:30:19 +0000

I like the idea of mapping values to BitmapData, I wrote a tiny BitmapDebugger class for the C64 hacking tool.
http://play.blog2t.net/flash-as3-c64-intro-previewer/

By: Ramon Fritsch

Ramon Fritsch — Mon, 23 Nov 2009 10:53:07 +0000

Yes, jonathan is right.

please change this:

var vectorDynamic:Vector. = new Vector.(1, false);
vectorDynamic[0] = 33;

var vectorFixed:Vector. = new Vector.(1, true);
vectorDynamic[0] = 33;

to this:

var vectorDynamic:Vector. = new Vector.(1, false);
vectorDynamic[0] = 33;

var vectorFixed:Vector. = new Vector.(1, true);
vectorFixed[0] = 33;

maybe the results will be different than now.

cheers