After installing the tuned ruby using https://gist.github.com/1688857 my specs run about 10-20% faster. No problems nor instabilities so far -> +1 :)
Updated patch against trunk.
This patch has been merged, no?
No. Most of code, but not packing of "st_table of any kind" nor ultrapacking.
I'll update patch against trunk in a day
Note that Qundef
cannot be appeared in st.c.
@nobu , but how then we should workaround hash behaviour? When we call to reject!
it uses st_delete_safe
with never
set to Qundef
, so that our current key is overwritten with Qundef
- and we could not find it in our keys.
Valuable option (as I think) is add ST_DELETE_SAFE
to enum st_retval
and/or add function st_foreach_safe
which accepts never
argument (and remove usage of st_delete_safe
from hash_foreach_iter
).
(I know that st_foreach_safe
exists in hash.c
, maybe use another name for it)
What is your opinion?
Sorry for trashing pool request :( I'll fix it today
I've updated patch.
Fifth commit (f67294a) is slightly backward incompatible, but ST_CHECK is used only in couple of places of standard library, and I could not find other usage nor by github, nor by google.
we've had some resque workers get stuck in an infinite loop during a find_entry (st.c) call with a 4 element cycle with this ultra packed perf patch. our build didn't include the 6270762 sha. problem doesn't seem to manifest under ruby-1.9.3_p125. it pains me to post this without a repro.
Hi, rboyd. I know about rare stuck with my performance patch :(
But latest version (not published yet) (well, it is part of tcs-ruby) were tested with another issue's reporter and he reports no problems found, - and it is clear backport of accepted changes (with packing, but without ultrapacking)
So that, I think ruby trunk has no bug.
Please, test tcs-ruby or ruby-trunk, not this pull request or previous version of patch.
I'll publish new version of patch soon, I just waited for tester's report. Could you report about your testing? You could do it here, at https://groups.google.com/forum/?fromgroups#!forum/thecodeshop , or by mail funny.falcon@gmail.com . Thanks.
|
nobu |
* st.c: fix packed num_entries on delete_safe. patched by Sokolov
…
Yura at ruby#84 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@34962 b2dd03c8-39d4-4d8f-98ff-823fe69b080e |
efae619
|
|
nobu |
* st.c: add st_foreach_check for fixing iteration over packed table
…
and st_delete_safe. patched by Sokolov Yura at ruby#84 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@34963 b2dd03c8-39d4-4d8f-98ff-823fe69b080e |
a73d958
|
|
nobu |
* st.c: pack tables also generic keys. patched by Sokolov Yura at
…
ruby#84 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@34964 b2dd03c8-39d4-4d8f-98ff-823fe69b080e |
3007acf
|
|
nobu |
* st.c: fix packed num_entries on delete_safe. patched by Sokolov
…
Yura at ruby#84 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@34962 b2dd03c8-39d4-4d8f-98ff-823fe69b080e |
8c7432a
|
|
nobu |
* st.c: add st_foreach_check for fixing iteration over packed table
…
and st_delete_safe. patched by Sokolov Yura at ruby#84 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@34963 b2dd03c8-39d4-4d8f-98ff-823fe69b080e |
9fc653a
|
|
nobu |
* st.c: pack tables also generic keys. patched by Sokolov Yura at
…
ruby#84 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@34964 b2dd03c8-39d4-4d8f-98ff-823fe69b080e |
44e126e
|
st: add st_foreach_check for fixing iteration over packed table and s… …
…t_delete_safe
Patch uses same technique as used for numhashes in trunk for packing tables of other types as well.
Also it use pointers in
st_table
structure (bins, head, tail) for packing tables of size 0 and 1, so that they need not to allocate bins at all.It gives great speedup for creating small hashes, and little overhead for bigger hashes. It gives very countable memory footprint reduction.
Investigation shows, that typical rails application allocates tons of small hashes. Up to 40% of whole allocated hashes never grows bigger than 1 element size.
Combined with #83 , it is faster than ruby-trunk even for hashes of sizes 7-10.
Performance testing using C extension is here https://gist.github.com/1626602 (also pool allocation patch tested here).