std.container.RedBlackTree versus C++ std::set

Dan dbdavidson at yahoo.com
Fri Feb 15 11:12:08 PST 2013


On Thursday, 14 February 2013 at 19:31:36 UTC, Steven 
Schveighoffer wrote:
>
> If it was pass by ref, then rbt.insert(5) would not work.  And 
> in fact, I wouldn't want things passed by ref if the element is 
> int.

What is the reason for the second objection - is just performance?
Is performance really an issue?

 From this thread it looks like fundamental types by ref or value 
is not really a big deal in terms of performance. OTOH - as size 
and/or postblit execution gets expensive the cost *is* 
significant.
---------------------------
4 bytes: using cref_(int size) took 29[ms]
4 bytes: using inref(int size) took 29[ms]
4 bytes: using in___(int size) took 30[ms]

8 bytes: using cref_(int size) took 29[ms]
8 bytes: using inref(int size) took 28[ms]
8 bytes: using in___(int size) took 31[ms]
...

128 bytes: using cref_(int size) took 29[ms]
128 bytes: using inref(int size) took 29[ms]
128 bytes: using in___(int size) took 290[ms]
---------------------------


> I have to admit, I did not consider expensive postblits when I 
> designed it.  Almost all my testing is with integer types.
>

For performance, it seems by ref should always be preferred in 
generic code because you can not know the cost of postblit - or 
copy construction if that were a future solution for structs. 
Granted the no rvalue passing is a pain - but is it a big deal in 
library/generic code?

Thanks,
Dan


More information about the Digitalmars-d-learn mailing list