Use hash for internal data store

[desmondmonster]

Use hash for internal data store

[zilkey]

Have you tried benchmarks just using a plain hash, instead of an OrderedHash? If OrderedHash is slowing things down, we could easily figure out a way to get rid of it. For example, calling all doesn't necessarily need to return things in the order added, so we could add sorts where necessary for all.

In that case another thing we should benchmark is the all method to make sure we're not making it too slow.

[desmondmonster]

Here are results for a plain hash. Ruby 1.9:

~/code/active_hash 1.9.3@active_hash [hash_finder]$ ruby benchmark.rb 
user     system      total        real
10th record id  0.000000   0.000000   0.000000 (  0.000980)
10th record where  9.990000   0.010000  10.000000 ( 10.007341)
1000th record id  0.000000   0.000000   0.000000 (  0.000793)
1000th record where 10.000000   0.010000  10.010000 ( 10.008452)

and Ruby 1.8:

~/code/active_hash 1.8.7@active_hash [hash_finder]$ ruby benchmark.rb 
user     system      total        real
10th record id  0.000000   0.000000   0.000000 (  0.001573)
10th record where 20.420000   0.010000  20.430000 ( 20.430843)
1000th record id  0.010000   0.000000   0.010000 (  0.001702)
1000th record where 21.140000   0.010000  21.150000 ( 21.146878)

No difference in find_by_id, but where improves to its original state. I'm surprised by the results in 1.9 since OrderedHash just passes everything up to its parent class, Hash. Maybe the extra requires are slowing it down?

I ran the same benchmark script, calling all 1000 times and the hash_finder branch is much slower than master:

~/code/active_hash 1.9.3@active_hash [hash_finder]$ ruby benchmark.rb 
user     system      total        real
all  0.810000   0.010000   0.820000 (  0.821074)

vs.

~/code/active_hash 1.9.3@active_hash [master]$ ruby benchmark.rb 
user     system      total        real
all  0.000000   0.000000   0.000000 (  0.000187)

Note that this is for returning 10,000 records. It's commensurately faster with a smaller dataset. But is it too slow?

[desmondmonster]

Turns out it was indeed too slow. I've taken another stab at it, this time retaining the @records array but converting the ids set to a full-fledged Hash that indexes a record's position in @records. Some additional memory is required, but benchmarks are speedy across the board. Here's Ruby 1.9:

~/code/active_hash 1.9.2@active_hash [index_finder]$ ruby benchmark.rb 
user     system      total        real
10th record id  0.000000   0.000000   0.000000 (  0.000743)
10th record where  9.930000   0.020000   9.950000 (  9.945236)
1000th record id  0.000000   0.000000   0.000000 (  0.000820)
1000th record where 10.010000   0.030000  10.040000 ( 10.037525)
all  0.000000   0.000000   0.000000 (  0.000273)

and Ruby 1.8:

~/code/active_hash 1.8.7@active_hash [index_finder]$ ruby benchmark.rb 
user     system      total        real
10th record id  0.000000   0.000000   0.000000 (  0.002309)
10th record where 19.330000   0.020000  19.350000 ( 19.373773)
1000th record id  0.000000   0.000000   0.000000 (  0.001875)
1000th record where 19.710000   0.030000  19.740000 ( 19.762334)
all  0.000000   0.000000   0.000000 (  0.000690)

I've pushed a new branch of master called index_finder with these changes. It's currently passing all specs. Let me know what you think!

[zilkey]

Rock on! I'll take a look tonight to make sure it works with a few of my existing projects as a final check, and release a new version as long as everything looks good. Thanks for putting in that extra work at the end - it seems a lot better to not regress on performance.

[zilkey]

I merged that branch and released a new version (0.9.12). And I really like this fix.

In fact, I think you just opened up an interesting new feature, which is indexes - it wouldn't take long to create a declarative syntax like:

indexes :id, :name

And then creates separate indexes for each. But that's for later....

Thanks for putting in all the effort.