[PATCH] D13545: [RuntimeDyld] Fix performance problem in resolveRelocations with many sections

[Lang Hames via llvm-commits]

lhames added a comment.

> This showed up heavily in an artificial julia benchmark that does lots of compilation. On that particular benchmark, this patch gives

>  ~15% performance improvements.


O_o

I'm fine with this change, but that result is surprising. Relocations is a:

  DenseMap<unsigned, SmallVector<RelocationEntry, 64>>

Constructing entries should be cheap relative to the rest of the compilation.

> After this one of the major performance drains is that creating a new pass manager for every module is pretty

>  expensive (see graph at the end of https://github.com/JuliaLang/julia/issues/9336)Is it possible to only construct

>  the pass manager once (I tried this briefly, but couldn't immediate make it work)? Does ORC maybe do this already?


ORC doesn't do this yet, but will definitely suffer the same performance issues, especialy when people use lazy compilation (which involves creating or breaking up modules).

A while back I actually tried persisting the pass manager in the ORC SimpleCompiler utility, and blew it up immediately on Darwin (and Linux too from memory). I'd be happy to turn that feature back on conditionally and add a test for it though: We should start tackling this. Plenty of people would love to be able to persist the pass manager.

RE switching Julia to MCJIT: Sounds cool. Shameless plug: I'd love to help you port to ORC if you're interested. If you're using the C++ APIs it's a trivial change (can be conditionally enabled to test it out), should be as fast or faster, and gets you some new features. :)


Repository:
  rL LLVM

http://reviews.llvm.org/D13545