Andrew Black wrote:
Greetings all.
Part of the intent for subversion submits r379032 through r379035 (as I
understand them) was to address some of the slowness in the stringstream
operations that was detected by the previous benchmarking run. With a
fresh benchmark run, the following are the results I get. Results are
user times in seconds, found by taking the average of 3 runs of 500000
itterations.
+-------------------+-------+------------+---------+
| stringstream_bm | glibc | stdcxx_old | stdcxx |
+-------------------+-------+------------+---------+
| read_write_multi | 0.68 | 1.05 | 1.05 |
| read_write_single | 7.99 | 14.43 | 14.41 |
| write_multi | 1.13 | 30.78 | 1.15 |
| write_read_cycle | 0.05 | 0.43 | 0.44 |
| write_read_multi | 7.58 | 46.53 | N/A |
| write_read_single | 8.08 | 45.76 | 15.37 |
| write_single | 2.00 | 31.02 | 2.36 |
| read_multi | 0.61 | 0.83 | 0.84 |
| read_single | 7.92 | 14.28 | 14.13 |
| read_write_cycle | 0.05 | 0.42 | 0.44 |
+-------------------+-------+------------+---------+
The bigest improvments spotted are in the write_single, write_multi, and
write_read_single tests (with the first two approaching the speed of
glibc). The write_read_multi test also showed a fair amount of
improvement (to 1.16 seconds),
Great! That's a significant improvement! I suspect the difference
we continue to see in some of these numbers might be due to the
allocation policy employed by our implementation which strives
for a balance between runtime speed and space efficiency. It would
be good to verify this hypothesis by changing our allocation policy
in the benchamrk to match the native one.
but the benchmark segfaults, so I must
discard the results of this test as unreliable.
I suppose it would make sense to note this failure with the STDCXX-149
JIRA incident.
I reproduced the core dump but I don't think there's anything wrong
with the library. I removed the stringstream code from the the test
and the program still core dumps (under Sun dbx), so it looks like
there's something wrong with the pointer arithmetic. I would suggest
to simplify the benchmark code so as not to rely on tricky pointer
manipulation and dynamic memory allocation (use std::string instead).
Martin
