Walter Bright <boost@xxxxxxxxxxxxxxx> writes: > On my project, one. But I've seen this problem repeatedly in other > projects that had multiple developers. For example, I used to use > version 1 of an assembler. It was itself written entirely in > assembler. It ran *incredibly* slowly on large asm files. But it was > written in assembler, which is very fast, so how could that be? > > Turns out, the symbol table used internally was a linear one. A > linear symbol table is easy to implement, but doesn't scale well at > all. Well, my first system was a Z80 computer with an editor/assembler in ROM (4kb). At one time I tried figuring out the size requirements of symbols. It was two bytes for each symbol. Namely the value. The "symbol table" was located behind the source code. Whenever this marvel of technology encountered a label, it searched the source code from the beginning for the definition of the label, keeping count of all label definitions in between. When it found the definition, the count corresponded to the position in the symbol table. So compilation times were O(ns), with n the number of symbol uses and s the size of the source code. Implementing in a higher language would not have helped: memory efficiency was what dictated this layout. Given that the whole available memory was perhaps 50kB, assembly language modules could not get so large that scale issues were deadly. But the assembly times did get annoying sometimes. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
