This is the mail archive of the
mailing list for the GCC project.
Re: Performance Gcc 3.3.1 VS 2.95.1
- From: Mike Capp <mike dot capp at gmail dot com>
- To: Joe dot Buck at synopsys dot com
- Cc: gcc at gnu dot org
- Date: Wed, 27 Oct 2004 13:37:16 +0100
- Subject: Re: Performance Gcc 3.3.1 VS 2.95.1
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=Itu7jQPe8kXXtoSEcDkA+Ypu8c2rqBj02kzH5OvjB9SgrCJu1956cNJNUb01uv79NUUSJxxpKo0R9zxshUMOMrUgGvH+5pc7D7w6QBoifncuBdgbvKI1zy9LyO7hKEPZNvvdkNryMBgCgKLXND9iLoyJedNG77BpFq8M6oVnZCc=
- Reply-to: Mike Capp <mike dot capp at gmail dot com>
> Ouch! By manipulating the capacity in that way, you force quadratic
> performance! The string has to be reallocated every time. Take out
> your explicit management of capacity and things will get much faster.
> If 2.95.1 ran this code faster, I assume it must have ignored your
>calls to reserve().
Not necessarily. basic_string::reserve guarantees *at least* the
requested capacity; it may well allocate more. If, f'rinstance,
2.95.1 rounded reservations up to the next multiple of 64 chars, and
3.3.1 rounded up to the next multiple of 16, then 3.3.1 would need to
reallocate more frequently, explaining the OP's performance
Don't know if this was actually the case; I'm just speculating.