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