forked from OSchip/llvm-project
e24605bbcd
These don't seem to have any real point. Let's start with IndexingContext. I can't come up with any conceivable reason to have many hundereds of thousands of these alive in an address space which would make the 4x difference in allocated (but unused) memory for the string scratch buffer a significant memory usage problem. The EditedSource one is somewhat more surprising. This is an 8x increase in the memory allocated (but not used) per editted source file. However, for this to realistically be a problem, you would need to have over half a million editted source files in a single address space, and even that would only really have problems on 32-bit Windows where you really only have 2gb of virtual address space. And what's more important, the fix to this if it is actually an issue shouldn't be to shrink the allocator's size, it is to pass a single allocator into *many* edited source file objects and let them share the memory. These were the only two uses of custom sized BumpPtrAllocators (excluding ones in the JIT using a custom allocation strategy) in all of LLVM, Clang, LLD, LLDB, or Polly. I don't think we actually need this complexity in the primary BumpPtrAllocator at all and am planning to remove it. llvm-svn: 204910 |
||
|---|---|---|
| .. | ||
| arcmt-test | ||
| c-arcmt-test | ||
| c-index-test | ||
| clang-check | ||
| clang-format | ||
| clang-format-vs | ||
| diag-build | ||
| diagtool | ||
| driver | ||
| libclang | ||
| scan-build | ||
| scan-view | ||
| CMakeLists.txt | ||
| Makefile | ||