Chris Lattner 16af11d962 It turns out that the two dimensional vectors were causing big slowdowns ... in this for programs with lots of types (like the testcase in PR224). The problem was that the type ID that the outer vector was using was not very dense (as many types are getting resolved), so the vector is large and gets reallocated a lot. Since there are a lot of values in the program (the .ll file is 10M), each reallocation has to copy the subvectors, which is also quite slow (this wouldn't be a problem if C++ supported move semantics, but it doesn't, at least not yet :( Changing the outer data structure to a map speeds a release build of llvm-as up from 11.21s to 5.13s on the testcase in PR224. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11244 91177308-0d34-0410-b5e6-96231b3b80d8		2004-02-09 21:03:38 +00:00
..
Analysis	Adjust to the changed StructType interface. In particular, getElementTypes() is gone.	2004-02-09 04:37:31 +00:00
Archive	* finegrainify namespacification of ArchiveReader.cpp	2004-01-10 19:00:15 +00:00
AsmParser	It turns out that the two dimensional vectors were causing big slowdowns	2004-02-09 21:03:38 +00:00
Bytecode	This debugging hook is no longer needed.	2004-02-09 17:20:52 +00:00
CodeGen	Move InstrSchedule's iterator begin/end methods inline.	2004-02-09 18:42:46 +00:00
Debugger	"fix" a nasty race condition	2004-01-14 21:18:03 +00:00
ExecutionEngine	Start using the new and improve interface to FunctionType arguments	2004-02-09 04:14:01 +00:00
Linker	Fixes for PR214. Use the SHLIBEXT variable instead of hardcoding .so into	2004-01-26 20:59:41 +00:00
Support	Fixes for PR214. Use the SHLIBEXT variable instead of hardcoding .so into	2004-01-26 20:59:41 +00:00
Target	Move InstrSchedule's iterator begin/end methods inline.	2004-02-09 18:42:46 +00:00
Transforms	Don't depend on auto data conversion	2004-02-09 05:16:30 +00:00
VMCore	Remove the statistics	2004-02-09 21:01:23 +00:00
Makefile	Add new dir	2004-01-05 05:25:59 +00:00