Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Maciej Stachowiak
> On Nov 20, 2014, at 4:51 PM, Maciej Stachowiak wrote: > >> >> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov > > wrote: >> >> >> 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov > > написал(а): >> >>> These and related uses are all over the p

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Maciej Stachowiak
> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov wrote: > > > 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov > написал(а): > >> These and related uses are all over the place - see also Vectors in >> FormDataBuilder, data returned from FrameLoader::loadResourceSynchr

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Filip Pizlo
> On Nov 20, 2014, at 2:06 PM, Alexey Proskuryakov wrote: > > > SmallVector and Vector seem reasonable to me. I think that this is the right > nomenclature - using limited size vectors should be a conscious choice. > > Even SmallVector should probably have a size_t API, so that we could > ce

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Alexey Proskuryakov
SmallVector and Vector seem reasonable to me. I think that this is the right nomenclature - using limited size vectors should be a conscious choice. Even SmallVector should probably have a size_t API, so that we could centralize magnitude checks. What do you think? - Alexey 20 нояб. 2014 г.,

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Antti Koivisto
Or Vector and ByteBuffer. All these cases requiring very large buffers seem to be about untyped data. antti On Thu, Nov 20, 2014 at 9:40 PM, Filip Pizlo wrote: > That looks like a pretty good performance win. > > I'd advocate for SmallVector and Vector, then. > > -Filip > > > On Nov 20, 20

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Filip Pizlo
That looks like a pretty good performance win. I'd advocate for SmallVector and Vector, then. -Filip > On Nov 20, 2014, at 11:38 AM, Chris Dumez wrote: > > The corresponding Blink bug did contain some performance data: > CrBug#229226

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Chris Dumez
The corresponding Blink bug did contain some performance data: CrBug#229226 Kr, -- Chris Dumez - Apple Inc. Cupertino, CA > On Nov 20, 2014, at 11:32 AM, Geoffrey Garen wrote: > >> I wonder what the downsides are to this approach.

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Filip Pizlo
If there was a benefit, then the following approach would make sense to me: - Have both Vector and SmallVector. SmallVector will use unsigned internally. - Use SmallVector in the places where sizeof(Vector) matters. This would take some effort but I think that we have the tools that would be n

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Geoffrey Garen
> I wonder what the downsides are to this approach. Footprint of Vector? It looks like the original change was motivated by shrinking Vector: https://bugs.webkit.org/show_bug.cgi?id=97268 Sadly, it didn’t include any data on the observed

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Filip Pizlo
I think I'm starting to see what you're saying, so let me restate it my way to be sure: Code that deals with various loaded blobs must be resilient against them getting larger than a 32-bit size can handle and this is the subject of ongoing development effort. Such code may or may not use a Ve

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Geoffrey Garen
Yes, good point. I should have been more specific. I believe this math might overflow and then truncate: template bool Vector::tryExpandCapacity(unsigned newMinCapacity) { return tryReserveCapacity(std::max(newMinCapacity, std::max(16u, static_cast(capacity() + capacity() / 4 + 1; } Ge

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Alexey Proskuryakov
20 нояб. 2014 г., в 10:45, Filip Pizlo написал(а): >> - uint64_t everywhere. This way, we'll solve practical problems with large >> resources once and for all. Also, this may prove to be necessary to solve >> even YouTube/Google Drive uploads, I do not know that yet. > > How does this solve t

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Filip Pizlo
> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov wrote: > > > 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov > написал(а): > >> These and related uses are all over the place - see also Vectors in >> FormDataBuilder, data returned from FrameLoader::loadResourceSynchr

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Alexey Proskuryakov
19 нояб. 2014 г., в 14:58, Alexey Proskuryakov написал(а): > These and related uses are all over the place - see also Vectors in > FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, > plug-in code that loads from network, SharedBuffer etc. Another way to say this is:

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

2014-11-20 Thread Carlos Garcia Campos
El mié, 19-11-2014 a las 12:20 -0800, Chris Dumez escribió: > Hi all, > > I recently started updating the WTF::Vector API to use unsigned types > instead of size_t [1][2], because: > - WTF::Vector is already using unsigned type for size/capacity > internally to save memory on 64-bit, causing a mis