On 01/29/2014 02:32 PM, Kinkie wrote:
> On Wed, Jan 29, 2014 at 7:52 PM, Alex Rousskov wrote:
>> On 01/29/2014 07:08 AM, Kinkie wrote:
> (in a trunk checkout)
> bzr diff -r lp:/squid/squid/vector-to-stdvector
>
> The resulting diff is reversed, but that should be easy enough to manage.
Thanks! Not sure whether reversing a diff in my head is easier than
downloading the branch :-(.
>> Can you give any specific examples of the code change that you would
>> attribute to a loss of performance when using std::vector? I did not
>> notice any obvious cases, but I did not look closely.
> I suspect that it's all those lines doing vector.items[accessor] and
> thus using C-style unchecked accesses.
std::vector[] element access operator does not check anything either, as
we discussed earlier. IIRC, you [correctly] used a few std::vector::at()
calls as well, but I did not see any in a critical performance path.
>>> test conditions:
>>> - done on rs-ubuntu-saucy-perf (4-core VM, 4 Gb RAM)
>>> - testing with ab. 1m requests @10 parallelism with keepalive,
>>> stressing the TCP_MEM_HIT code path on a cold cache
>>> - test on a multicore VM; default out-of-the-box configuration, ab
>>> running on same hardware over the loopback interface.
>>> - immediately after ab exits, collect counters (mgr:counters)
>>>
>>> numbers (for trunk / stdvector)
>>> - mean response time: 1.032/1.060ms
>>> - cpu_time: 102.878167/106.013725
> If you can suggest a more thorough set of commands using the rough
> tools I have, I'll gladly run them.
How about repeating the same pair of tests a few times, in random order?
Do you get consistent results?
Thank you,
Alex.
Received on Wed Jan 29 2014 - 23:39:29 MST
This archive was generated by hypermail 2.2.0 : Fri Jan 31 2014 - 12:00:17 MST