[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
From:
Eric Wong <normalperson@...>
Date:
2015-08-12 23:07:42 UTC
List:
ruby-core #70358
SASADA Koichi <ko1@atdot.net> wrote: > On 2015/08/13 4:29, Юрий Соколов wrote: > > I thought to suggest to embed hash_id_table directly into places when it > > is used (instead of pointer to). > > It will use 24byte on 64bit platform, so not too big. > > It has benefit when used with jemalloc/tcmalloc which are good at > > allocating sizes = 2**x. > > With flexible array size will be not equal to power of 2, so that they > > will consume a bit more memory on big tables. > > > > But I think flexible array are also very good idea. > > Let me know, if I need to fix hash variant for this. > > For flexible array, I'm negative because it can conflict usage like > updating tables during foreach, and so on. Just now, we need to clear > usages first. I think impact of flexible array is not so big (compare > with current implementation), or so big? Probably makes most difference with few (1..5) maybe? elements. Since this is for internal use, we should disallow updates during iteration. It makes very complicated corner cases in st.c > For embedding tables, I also negative because we need to expose table > data structure for users. Just now, I want to hide it into id_table.c. > Of course, if we decide this implementation finally, we can try it. I see no problem exposing data structures to internal.h users. Just keep it out of public C API. Only downside is increased compile time for C Ruby devs (I use ccache).