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

Zachary Turner via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 9 10:26:30 PDT 2016


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/0c5d8e76/attachment.html>


More information about the llvm-commits mailing list