-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/2010 01:13 PM, vicente.botet wrote:
Are you saying that given the following functions
xint::integer cow(); boost::rv<xint::integer> m(); xint::integer i;
i = cow() is faster than i = m() on a single thread environement?
That's exactly what I'm saying. Which makes some sense, when you think about it... if the compiler doesn't optimize it perfectly, then it's spending CPU cycles to create the the boost::rv type, only to assign it to another integer and destroy it again. Copy-on-write doesn't need to do any of that.
If yet, what is the ratio you have measured?
It looks like I didn't save the file with the results, but they were something like copy-on-write being 0.3 seconds faster than neither, and move being about 0.15 seconds faster. The test took roughly three seconds at its fastest, if I recall correctly, which would make copy-on-write about 5% faster than move semantics if I've got my sums correct. (The ratio could vary depending on the size of the numbers used though. Larger numbers *should* produce larger savings, since copying them would be more expensive. Though the library would also spend more time within the functions processing each number, so I'm not certain about that.) I'll have to recreate that test code anyway, in order to see how the random number locking affected the speed, so I'll have more detailed results to post later today. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvdu+YACgkQp9x9jeZ9/wRiPACg73Mc9wp3Ldnc8cIuwURpFevd mZ8AniHgHr1WH1PXYtb1dL0XZK6j1xoh =uioo -----END PGP SIGNATURE-----