* [ruby-core:66767] [ruby-trunk - Feature #10585] [Open] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
@ 2014-12-10 14:41 ` funny.falcon
2014-12-11 23:04 ` [ruby-core:66792] " Eric Wong
2014-12-11 23:08 ` [ruby-core:66793] [ruby-trunk - Feature #10585] " normalperson
` (7 subsequent siblings)
8 siblings, 1 reply; 14+ messages in thread
From: funny.falcon @ 2014-12-10 14:41 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been reported by Yura Sokolov.
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66792] Re: [ruby-trunk - Feature #10585] [Open] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
2014-12-10 14:41 ` [ruby-core:66767] [ruby-trunk - Feature #10585] [Open] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs funny.falcon
@ 2014-12-11 23:04 ` Eric Wong
0 siblings, 0 replies; 14+ messages in thread
From: Eric Wong @ 2014-12-11 23:04 UTC (permalink / raw)
To: Ruby developers
benchmark results on r48774 (Xeon E3-v1230 v3):
Speedup ratio: compare with the result of `trunk' (greater is better)
name built
loop_whileloop2 1.001
vm2_struct_big_aref_hi* 1.006
vm2_struct_big_aref_lo* 1.000
vm2_struct_big_aset* 1.005
vm2_struct_big_href_hi* 1.466
vm2_struct_big_href_lo* 1.213
vm2_struct_big_hset* 1.305
vm2_struct_small_aref* 1.010
vm2_struct_small_aset* 2.604
vm2_struct_small_href* 1.215
vm2_struct_small_hset* 1.215
Comments on patches:
* [1/4] struct.c: speedup struct.name = v for small structs
I agree this makes a noticeable improvement, but I am also not
in favor of more specialized C code. One day, I hope we
can remove the current optimizations for <10 getters with JIT.
* [2/4] struct.c: cache member definition in a subclass
I think NIL_P(var) is preferred over "var != Qnil".
Overall, I think this patch makes sense on its own.
* [3/4] benchmark struct[:name]
Good :)
* [4/4] struct.c: speedup for big structs
Oops, I totally missed some of these in [Feature #10575]
I'm unsure about having a custom hash table in there
is best, perhaps it can be extracted and reused for
other things (fstring).
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66793] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
2014-12-10 14:41 ` [ruby-core:66767] [ruby-trunk - Feature #10585] [Open] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs funny.falcon
@ 2014-12-11 23:08 ` normalperson
2014-12-12 9:16 ` [ruby-core:66803] " funny.falcon
` (6 subsequent siblings)
8 siblings, 0 replies; 14+ messages in thread
From: normalperson @ 2014-12-11 23:08 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Eric Wong.
benchmark results on r48774 (Xeon E3-v1230 v3):
Speedup ratio: compare with the result of `trunk' (greater is better)
name built
loop_whileloop2 1.001
vm2_struct_big_aref_hi* 1.006
vm2_struct_big_aref_lo* 1.000
vm2_struct_big_aset* 1.005
vm2_struct_big_href_hi* 1.466
vm2_struct_big_href_lo* 1.213
vm2_struct_big_hset* 1.305
vm2_struct_small_aref* 1.010
vm2_struct_small_aset* 2.604
vm2_struct_small_href* 1.215
vm2_struct_small_hset* 1.215
Comments on patches:
* [1/4] struct.c: speedup struct.name = v for small structs
I agree this makes a noticeable improvement, but I am also not
in favor of more specialized C code. One day, I hope we
can remove the current optimizations for <10 getters with JIT.
* [2/4] struct.c: cache member definition in a subclass
I think NIL_P(var) is preferred over "var != Qnil".
Overall, I think this patch makes sense on its own.
* [3/4] benchmark struct[:name]
Good :)
* [4/4] struct.c: speedup for big structs
Oops, I totally missed some of these in [Feature #10575]
I'm unsure about having a custom hash table in there
is best, perhaps it can be extracted and reused for
other things (fstring).
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50367
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66803] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
2014-12-10 14:41 ` [ruby-core:66767] [ruby-trunk - Feature #10585] [Open] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs funny.falcon
2014-12-11 23:08 ` [ruby-core:66793] [ruby-trunk - Feature #10585] " normalperson
@ 2014-12-12 9:16 ` funny.falcon
2014-12-12 10:42 ` [ruby-core:66806] " Eric Wong
2014-12-12 9:39 ` [ruby-core:66805] " ko1
` (5 subsequent siblings)
8 siblings, 1 reply; 14+ messages in thread
From: funny.falcon @ 2014-12-12 9:16 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Yura Sokolov.
> [1/4] struct.c: speedup struct.name = v for small structs
> I agree this makes a noticeable improvement, but I am also not
> in favor of more specialized C code. One day, I hope we
> can remove the current optimizations for <10 getters with JIT.
But till JIT is implemented it will be useful to have fast structs.
I was really disappointed when I discovered that `struct.name= v`
is much slower than `object.name= v` when `name` defined with `attr_accessor`.
> [4/4] struct.c: speedup for big structs
> Oops, I totally missed some of these in [Feature #10575]
> I'm unsure about having a custom hash table in there
> is best, perhaps it can be extracted and reused for
> other things (fstring).
It is very simplified cause members count doesn't change. So it is unusable for fstring.
And it uses Array as a storage for simplicity.
Is using st_table for fstring a bottleneck? if so, i could implement lighter hash structure for.
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50376
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66805] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
` (2 preceding siblings ...)
2014-12-12 9:16 ` [ruby-core:66803] " funny.falcon
@ 2014-12-12 9:39 ` ko1
2014-12-12 10:48 ` [ruby-core:66807] " normalperson
` (4 subsequent siblings)
8 siblings, 0 replies; 14+ messages in thread
From: ko1 @ 2014-12-12 9:39 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Koichi Sasada.
I don't have any idea about these patch.
In fact, I like 0001.
So just comments and questions for curious.
> I was really disappointed when I discovered that struct.name= v
> is much slower than object.name= v when name defined with attr_accessor.
How about to implement Struct as attr_setter?
----
Another question is "how many people use Struct?".
Do you know? Any trouble on performance of Struct?
Ruby has Hash object and Class's attribute. Most of people using them.
Only I know is the book "understanding computation" :)
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50378
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66806] Re: [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
2014-12-12 9:16 ` [ruby-core:66803] " funny.falcon
@ 2014-12-12 10:42 ` Eric Wong
0 siblings, 0 replies; 14+ messages in thread
From: Eric Wong @ 2014-12-12 10:42 UTC (permalink / raw)
To: Ruby developers
funny.falcon:
I tried using khash fstring for Feature #10096 but benefits seemed
minor. I also worry about executable size getting bigger every
release... Maybe using Array storage + open address hash can save
space (both runtime memory and execuatable size).
ko1:
Feature #10575 was inspired by a private (crazy) project many years
ago. As a C programmer learning Ruby, I expected Ruby Struct to be
similar to C struct and offer performance characteristics of an array.
I had 200-500 member (auto-generated) Ruby Structs and noticed speed
problems. It was easier to rewrite Ruby code at the time (to use
hashes or attr), so I rewrote my code and forgot about struct.c
However, I still hope to spare others from having to learn VM
internals or rewrite any Ruby code for consistent performance.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66807] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
` (3 preceding siblings ...)
2014-12-12 9:39 ` [ruby-core:66805] " ko1
@ 2014-12-12 10:48 ` normalperson
2014-12-12 17:03 ` [ruby-core:66811] " funny.falcon
` (3 subsequent siblings)
8 siblings, 0 replies; 14+ messages in thread
From: normalperson @ 2014-12-12 10:48 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Eric Wong.
funny.falcon:
I tried using khash fstring for Feature #10096 but benefits seemed
minor. I also worry about executable size getting bigger every
release... Maybe using Array storage + open address hash can save
space (both runtime memory and execuatable size).
ko1:
Feature #10575 was inspired by a private (crazy) project many years
ago. As a C programmer learning Ruby, I expected Ruby Struct to be
similar to C struct and offer performance characteristics of an array.
I had 200-500 member (auto-generated) Ruby Structs and noticed speed
problems. It was easier to rewrite Ruby code at the time (to use
hashes or attr), so I rewrote my code and forgot about struct.c
However, I still hope to spare others from having to learn VM
internals or rewrite any Ruby code for consistent performance.
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50379
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66811] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
` (4 preceding siblings ...)
2014-12-12 10:48 ` [ruby-core:66807] " normalperson
@ 2014-12-12 17:03 ` funny.falcon
2014-12-12 22:01 ` [ruby-core:66815] " Eric Wong
2014-12-12 22:08 ` [ruby-core:66816] " normalperson
` (2 subsequent siblings)
8 siblings, 1 reply; 14+ messages in thread
From: funny.falcon @ 2014-12-12 17:03 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Yura Sokolov.
khash were not best solution cause it doesn't store hashsum. Did you store string's hashsum as a part of a key?
But i doubt fstring need fast hash. And it needs deletions, so hash table could not be simple any way. Or am i mistaken?
But if fast hash table will be used for other tables (method table, instance variables,for example), that it worth to implement one.
I had done fast symbol table for ruby 1.9.3 and it were not accepted. I've done method cache which is used in github ruby build, but not accepted in mainline.
If one wants to be fast, one need to build specialised structures, and it leads to code bloat, so it is not accepted into mainline.
If there is real need to improve certain place by fast hash table, i will do it with pleasure. But it looks like there is no need.
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50382
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66815] Re: [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
2014-12-12 17:03 ` [ruby-core:66811] " funny.falcon
@ 2014-12-12 22:01 ` Eric Wong
0 siblings, 0 replies; 14+ messages in thread
From: Eric Wong @ 2014-12-12 22:01 UTC (permalink / raw)
To: Ruby developers
funny.falcon@gmail.com wrote:
> khash were not best solution cause it doesn't store hashsum. Did you
> store string's hashsum as a part of a key?
No, I considered doing that but never got around to it.
I worry more about memory usage.
> But i doubt fstring need fast hash. And it needs deletions, so hash
> table could not be simple any way. Or am i mistaken?
khash is fast enough for current uses, I think. However, I was
sad when r43870 needed to be reverted [misc #9188]
> But if fast hash table will be used for other tables (method table,
> instance variables,for example), that it worth to implement one.
I suspect ordering matters for those, unfortunately [Feature #9614]
> I had done fast symbol table for ruby 1.9.3 and it were not accepted.
> I've done method cache which is used in github ruby build, but not
> accepted in mainline.
Symbol table was largely redone for 2.2 and memory usage decreased a
little. I still hope we can remove the global method cache someday
(and only use inline cache).
> If one wants to be fast, one need to build specialised structures, and
> it leads to code bloat, so it is not accepted into mainline.
Sometimes. st performance is good, but it is wasteful.
I've been trying to move to generic stuff, e.g. with ccan/list.
For 2.3, I plan to use ccan/list in st.c [misc #10278] and also
in compile.c (and maybe gc.c).
> If there is real need to improve certain place by fast hash table, i
> will do it with pleasure. But it looks like there is no need.
Fair enough.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66816] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
` (5 preceding siblings ...)
2014-12-12 17:03 ` [ruby-core:66811] " funny.falcon
@ 2014-12-12 22:08 ` normalperson
2014-12-15 18:29 ` [ruby-core:66851] " funny.falcon
2015-06-24 9:08 ` [ruby-core:69729] [Ruby trunk " funny.falcon
8 siblings, 0 replies; 14+ messages in thread
From: normalperson @ 2014-12-12 22:08 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Eric Wong.
funny.falcon@gmail.com wrote:
> khash were not best solution cause it doesn't store hashsum. Did you
> store string's hashsum as a part of a key?
No, I considered doing that but never got around to it.
I worry more about memory usage.
> But i doubt fstring need fast hash. And it needs deletions, so hash
> table could not be simple any way. Or am i mistaken?
khash is fast enough for current uses, I think. However, I was
sad when r43870 needed to be reverted [misc #9188]
> But if fast hash table will be used for other tables (method table,
> instance variables,for example), that it worth to implement one.
I suspect ordering matters for those, unfortunately [Feature #9614]
> I had done fast symbol table for ruby 1.9.3 and it were not accepted.
> I've done method cache which is used in github ruby build, but not
> accepted in mainline.
Symbol table was largely redone for 2.2 and memory usage decreased a
little. I still hope we can remove the global method cache someday
(and only use inline cache).
> If one wants to be fast, one need to build specialised structures, and
> it leads to code bloat, so it is not accepted into mainline.
Sometimes. st performance is good, but it is wasteful.
I've been trying to move to generic stuff, e.g. with ccan/list.
For 2.3, I plan to use ccan/list in st.c [misc #10278] and also
in compile.c (and maybe gc.c).
> If there is real need to improve certain place by fast hash table, i
> will do it with pleasure. But it looks like there is no need.
Fair enough.
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50385
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:66851] [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
` (6 preceding siblings ...)
2014-12-12 22:08 ` [ruby-core:66816] " normalperson
@ 2014-12-15 18:29 ` funny.falcon
2015-06-22 22:31 ` [ruby-core:69705] " Eric Wong
2015-06-24 9:08 ` [ruby-core:69729] [Ruby trunk " funny.falcon
8 siblings, 1 reply; 14+ messages in thread
From: funny.falcon @ 2014-12-15 18:29 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Yura Sokolov.
File 0002-struct.c-cache-member-definition-in-a-subclass.patch added
uploaded 0002 with NIL_P instead of == Qnil
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50412
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:69705] Re: [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
2014-12-15 18:29 ` [ruby-core:66851] " funny.falcon
@ 2015-06-22 22:31 ` Eric Wong
2015-06-30 20:13 ` [ruby-core:69821] " Eric Wong
0 siblings, 1 reply; 14+ messages in thread
From: Eric Wong @ 2015-06-22 22:31 UTC (permalink / raw)
To: Ruby developers
Thanks, I've committed 0002, 0003, and would like to commit a
slightly-updated 0004 soon unless somebody else objects:
Updated 0004:
http://80x24.org/spew/m/f5c7f28bff5e378b71425ac78f043b5093dac1f4.txt
I'm not a big fan of 0001, though...
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:69729] [Ruby trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
` (7 preceding siblings ...)
2014-12-15 18:29 ` [ruby-core:66851] " funny.falcon
@ 2015-06-24 9:08 ` funny.falcon
8 siblings, 0 replies; 14+ messages in thread
From: funny.falcon @ 2015-06-24 9:08 UTC (permalink / raw)
To: ruby-core
Issue #10585 has been updated by Yura Sokolov.
imho, 0001 is very important, cause it gives most of performance improvement for usual case.
For now, I think twice: use struct or object, despite that struct is looking better and provides smaller and cleaner code.
If setter's will be faster, than struct will be much more usable.
----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-53110
* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
0001 - Define optimized setters for first 10 attributes.
0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.
0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.
---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ruby-core:69821] Re: [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
2015-06-22 22:31 ` [ruby-core:69705] " Eric Wong
@ 2015-06-30 20:13 ` Eric Wong
0 siblings, 0 replies; 14+ messages in thread
From: Eric Wong @ 2015-06-30 20:13 UTC (permalink / raw)
To: Ruby developers
Eric Wong <normalperson@yhbt.net> wrote:
> Thanks, I've committed 0002, 0003, and would like to commit a
> slightly-updated 0004 soon unless somebody else objects:
>
> Updated 0004:
> http://80x24.org/spew/m/f5c7f28bff5e378b71425ac78f043b5093dac1f4.txt
Will also squash the following.
http://80x24.org/spew/m/20150630201102.GA14164@dcvr.yhbt.net.txt
> I'm not a big fan of 0001, though...
OK, I'll reconsider it for 2.3.0 since I haven't seen any JIT work land,
yet.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-06-30 19:48 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <redmine.issue-10585.20141210144130@ruby-lang.org>
2014-12-10 14:41 ` [ruby-core:66767] [ruby-trunk - Feature #10585] [Open] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs funny.falcon
2014-12-11 23:04 ` [ruby-core:66792] " Eric Wong
2014-12-11 23:08 ` [ruby-core:66793] [ruby-trunk - Feature #10585] " normalperson
2014-12-12 9:16 ` [ruby-core:66803] " funny.falcon
2014-12-12 10:42 ` [ruby-core:66806] " Eric Wong
2014-12-12 9:39 ` [ruby-core:66805] " ko1
2014-12-12 10:48 ` [ruby-core:66807] " normalperson
2014-12-12 17:03 ` [ruby-core:66811] " funny.falcon
2014-12-12 22:01 ` [ruby-core:66815] " Eric Wong
2014-12-12 22:08 ` [ruby-core:66816] " normalperson
2014-12-15 18:29 ` [ruby-core:66851] " funny.falcon
2015-06-22 22:31 ` [ruby-core:69705] " Eric Wong
2015-06-30 20:13 ` [ruby-core:69821] " Eric Wong
2015-06-24 9:08 ` [ruby-core:69729] [Ruby trunk " funny.falcon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).