Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43FA4647.9040506@roguewave.com>
Date: Mon, 20 Feb 2006 15:44:23 -0700
From: Andrew Black <ablack@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: Benchmarking stdcxx
References: <43ECE5A3.1070609@roguewave.com> <43EFC2A3.3030608@roguewave.com>
In-Reply-To: <43EFC2A3.3030608@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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), 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.

--Andrew Black