Heyas, On Mon, Apr 28, 2008 at 6:27 PM, grischka <[EMAIL PROTECTED]> wrote: > From: "egodust": > > > > I am using: > > > > advapi32.def, comdlg32.def, gdi32.def, kernel32.def, msvcrt.def, > > ole32.def, shell32.def, shlwapi.def, user32.def, ws2_32.def > > > > In total there are 4334 function names -- this information rarely > > changes and is parsed from disk with each tcc_new()! > > Okay, but what is that compared to including windows.h?
Well, once code has been compiled, objects are written and these are reused until source changes, which means the ~3000 lines of winuser.h aren't really that important :) -- however, linking *always* happens, even for cached objects, so those functions are always loaded. I don't want the linker to re-read the DEF files for each object during link, I know its my fault my design uses multiple states, but still :) -- Why does it even need to load everything into memory? I wrote a test linker with some changes: 1. the DEF files are sorted (currently DEF files are not in true sorted order) 2. using a binary search on the DEF file and a MRU list, I was able to keep the number of symbols in memory to a minimum, a ~650 line file, takes ~13 lookups. I don't really care that the DEF files have to be loaded into memory, but it'd be nice if the information wasn't duplicated/read across different states, hence the API.. I doubt most people will use libtcc this way. > > > > I also thought about adding a new API layer, i.e. libtccadv (advanced) > > which contains such APIs, that aren't recommended for most uses... > > An API that is not recommended for use? ;) Not for noobs :) > > > Kind Regards, > > Sam K > > --- grischka _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
