search for: indivisble

...fully not to waste time on initial load, but if you do, reading data required for symbol resolution from ELF file should be satisfactory fast (I did that for COFF -- the current "atom-based ELF" linker is doing too much things in an initial load, like read all relocation tables, splitting indivisble chunk of data and connect them with "indivisible" edges, etc.) Looks like we read symbol table pretty quickly in the new implementation, and the bottleneck of it is now the time to insert symbols into the symbol hash table -- which you cannot make faster by changing object file format. S...

...gt; time on initial load, but if you do, reading data required for symbol > resolution from ELF file should be satisfactory fast (I did that for COFF > -- the current "atom-based ELF" linker is doing too much things in an > initial load, like read all relocation tables, splitting indivisble chunk > of data and connect them with "indivisible" edges, etc.) Looks like we read > symbol table pretty quickly in the new implementation, and the bottleneck > of it is now the time to insert symbols into the symbol hash table -- which > you cannot make faster by changing ob...

...initial load, but if you do, reading data required for symbol >> resolution from ELF file should be satisfactory fast (I did that for COFF >> -- the current "atom-based ELF" linker is doing too much things in an >> initial load, like read all relocation tables, splitting indivisble chunk >> of data and connect them with "indivisible" edges, etc.) Looks like we read >> symbol table pretty quickly in the new implementation, and the bottleneck >> of it is now the time to insert symbols into the symbol hash table -- which >> you cannot make faste...

..., but if you do, reading data required for symbol >>> resolution from ELF file should be satisfactory fast (I did that for COFF >>> -- the current "atom-based ELF" linker is doing too much things in an >>> initial load, like read all relocation tables, splitting indivisble chunk >>> of data and connect them with "indivisible" edges, etc.) Looks like we read >>> symbol table pretty quickly in the new implementation, and the bottleneck >>> of it is now the time to insert symbols into the symbol hash table -- which >>> you c...

...do, reading data required for symbol >>>> resolution from ELF file should be satisfactory fast (I did that for COFF >>>> -- the current "atom-based ELF" linker is doing too much things in an >>>> initial load, like read all relocation tables, splitting indivisble chunk >>>> of data and connect them with "indivisible" edges, etc.) Looks like we read >>>> symbol table pretty quickly in the new implementation, and the bottleneck >>>> of it is now the time to insert symbols into the symbol hash table -- which >&g...

On May 28, 2015, at 5:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > I guess, looking back at Nick's comment: > > "The atom model is a good fit for the llvm compiler model for all architectures. There is a one-to-one mapping between llvm::GlobalObject (e.g. function or global variable) and lld:DefinedAtom." > > it seems that the primary issue on the

...data required for symbol >>>>> resolution from ELF file should be satisfactory fast (I did that for COFF >>>>> -- the current "atom-based ELF" linker is doing too much things in an >>>>> initial load, like read all relocation tables, splitting indivisble chunk >>>>> of data and connect them with "indivisible" edges, etc.) Looks like we read >>>>> symbol table pretty quickly in the new implementation, and the bottleneck >>>>> of it is now the time to insert symbols into the symbol hash table --...