[PATCH] D21157: [pdb] Improve StreamInterface to support writing

[Zachary Turner via llvm-commits]

On second thought i think i can actually make that work. I was thinking
you'd want a full blown interval tree, but it could be done using the same
walk I'm doing for writing. Since this is still a rare case, I'm fine
adding this, or not adding it, depending on what people prefer
On Thu, Jun 9, 2016 at 10:26 AM Zachary Turner <zturner at google.com> wrote:

> Ob, one more thing. Larger queries will still be reused IF offset of the
> previous request is the same as offset of the current request.
>
> What doesn't work is if they overlap but start at different locations. Eg
>
> Read 1: offset 0, length 1024
> Read 2: offset 512, length 256
>
> Even in that case though, if the 256 byte read didn't cross the
> discontinuity, it would be satisfied without the cache. So probability is
> very low of running into this
> On Thu, Jun 9, 2016 at 10:22 AM Zachary Turner <zturner at google.com> wrote:
>
>> zturner added inline comments.
>>
>> ================
>> Comment at: lib/DebugInfo/PDB/Raw/MappedBlockStream.cpp:47-48
>> @@ -46,3 +46,4 @@
>>
>>    auto CacheIter = CacheMap.find(Offset);
>>    if (CacheIter != CacheMap.end()) {
>> +    // Try to find an alloc that was large enough for this request.
>> ----------------
>> majnemer wrote:
>> > Doesn't this mean that larger queries that happened earlier are not
>> reused?
>> >
>> > Let's say we start with an empty cache.
>> > Then a read request for 4096 bytes from offset 0 happens.
>> > Then a read request for 1024 bytes at offset 1024 happens.
>> > Won't the second request not share with the first?
>> You are correct.  And I thought of that, but it makes the data structure
>> more complicated, and I didn't think it was worth it for a code path that
>> would almost never get exercised anyway.  This is mostly here so you don't
>> shoot yourself in the foot, but as Rui mentioned earlier, read/write on the
>> same pdb is not going to be a common thing at all, so I made it just smart
>> enough that if you use it your program will still work, but still stupid
>> enough that I didn't have to devise a new complicated data structure.
>>
>>
>> http://reviews.llvm.org/D21157
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160609/99f2287e/attachment.html>