[PATCH] D62188: Speed up --start-lib and --end-lib.

[Rui Ueyama via Phabricator via llvm-commits]

ruiu added a comment.

In D62188#1511412 <https://reviews.llvm.org/D62188#1511412>, @MaskRay wrote:

> In LazyObjFile::parse():
>
>   for (size_t I = FirstGlobal, End = ESyms.size(); I != End; ++I)
>     if (ESyms[I].st_shndx != SHN_UNDEF)
>       // resolveSymbol() called by addSymbol() checks if the symbol was originally undefined.
>       // If that is the case, addSymbol() will transitively call SymbolTable::fetchLazy, which calls LazyObjFile::fetch().
>       this->Symbols[I] = Symtab->addSymbol(
>           LazyObject{*this, CHECK(ESyms[I].getName(Strtab), this)});
>   return;


Good point. I didn't think about that, but looks like that's a problem. I believe this can be fixed by inserting placeholder symbols first and then resolve them against LazyObject symbols. Let me try to do that.

> In LazyObjFile::parse():
> 
>   // Symbols[0,I) are inherited from LazyObjFile::parse(), other entries are nullptr.
>   // This has another problem: it increases memory usage.
>   // The copy assignment cannot be replaced with move assignment, because
>   // parse() will continue processing Symbols[I+1] Symbols[I+2] ...
>   File->Symbols = Symbols;
>    
> 
> I think in most cases (that are not flagged by `--warn-backrefs`), this may not have a perceivable improvement in the current form. Actually,
>  For an (input: 4.2G; output: 1.6G) executable, I measure a performance regression, 1% or lower, but the memory usage increases by ~1.6%. Do you know if the problem can be fixed?

What program did you use for your testing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62188/new/

https://reviews.llvm.org/D62188