Re: [Boost-users] Compress to buffer

Subject: Re: [Boost-users] Compress to buffer
From: Kenneth Adam Miller (kennethadammiller_at_[hidden])
Date: 2014-01-16 17:58:00

Ok. Well all my producer does is append. Vector sounds good for the ability
to do random access fast like an array, and you said that vector has good
append speed.

On Thu, Jan 16, 2014 at 4:48 PM, Gavin Lambert <gavinl_at_[hidden]>wrote:

> On 17/01/2014 11:27, Quoth Kenneth Adam Miller:
>
>  Ah ok. Well I didn't know, what I thought was, if the word size of the
>> machine was 8 bytes, then each clock cycle move would result in 8 bytes
>> being moved. I wasn't sure though that's why I asked. I know it's silly
>> to consider this level of optimization, but I question things extremely
>> hard lol. Thanks, the list of errors the compiler was giving was just
>> overwhelming.
>>
>
> You can get that speed benefit if you use a string and you make a copy of
> the entire string -- the STL usually optimises this to a memcpy, which will
> do an intelligent data blit.
>
> Vector typically doesn't do that, it'll make an element-by-element copy,
> although the compiler *might* be smart enough to optimise that away to a
> memcpy-like blit.
>
> But neither is likely to be any better than the other for insertion.  If
> your source is producing chars then you're just going to waste more time
> trying to merge and combine writes than it would to just do byte writes in
> the first place.  And a vector of 64-bit values doesn't have any way to
> express a number of bytes less than a multiple of 64 bits, so you would be
> forced to have padding.
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>