[PATCH] D45003: [Support] Make line-number cache robust against access patterns.

[Graydon Hoare via Phabricator via llvm-commits]

graydon created this revision.
graydon added a reviewer: jordan_rose.

The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.

When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.

This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending pointers, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.

Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). But the main
motive here is to make-impossible the cases we don't always see, that show up
by surprise when there is an out-of-order access pattern.


Repository:
  rL LLVM

https://reviews.llvm.org/D45003

Files:
  include/llvm/Support/SourceMgr.h
  lib/Support/SourceMgr.cpp
  unittests/Support/SourceMgrTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D45003.140151.patch
Type: text/x-patch
Size: 7249 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180328/c99a2ed2/attachment.bin>