Re: Re[2]: [sqlite] Performance & database design

[Jay Sprenkle]

On 3/22/06, Teg <[EMAIL PROTECTED]> wrote:
> Hello Jay,
>
> Best way I've found to get great performance out of strings and
> vectors is to re-use the strings and vectors. String creation speed is
> completely dependent on allocation speed so, by re-using the strings,
> you only grow the ones that aren't already big enough to hold the new
> string data so, eventually they don't grow at all.
>
> At least with STLPort STL which I use, a "clear" doesn't de-allocate
> the space then re-use simply fills in the already allocated space.
>
> With re-use, speeds are easily as fast as straight C after an initial
> setup time.

Ah. There is a method to set the size of the vector if you know what it will be
in advance. It's a great deal faster not to pay for all the repeated
reallocation
and memory movement if you can code it that way.

Re[2]: [sqlite] Performance & database design

[Teg]

Hello Jay,

Best way I've found to get great performance out of strings and
vectors is to re-use the strings and vectors. String creation speed is
completely dependent on allocation speed so, by re-using the strings,
you only grow the ones that aren't already big enough to hold the new
string data so, eventually they don't grow at all.

At least with STLPort STL which I use, a "clear" doesn't de-allocate
the space then re-use simply fills in the already allocated space.

With re-use, speeds are easily as fast as straight C after an initial
setup time.


C

Wednesday, March 22, 2006, 6:20:07 PM, you wrote:

JS> On 3/22/06, Micha Bieber
JS> <[EMAIL PROTECTED]> wrote:
>> Eventually, I've got my lesson. Because it might be of some interest for
>> the beginner:
>>
>> 1)Use the associated sqlite3_bind_* variants for your data.
>> I did make a mistake in converting forth and back to strings beforehand.
>>
>> 2)It broke my program design a bit, but setting up large STL vector
>> based C++ string records (especially using push_back and stringstreams
>> for conversions) turned out to be a show stopper on some platforms. The
>> plan was, to feed them to sqlite_bind* later on (with the additional
>> performance drop caused by exclusively using sqlite3_bind_text mentioned
>> above). Setting up the structures took more time than the asynchronous
>> writing to the database.

JS> Huh. I'll have to do some testing. I thought vector was pretty speedy.
JS> Thanks for posting your results!



-- 
Best regards,
 Tegmailto:[EMAIL PROTECTED]