Glancing at Pike I notice that:
- The i386 compiled 32 bit binary is roughly 2MB text size and 866KB BSS
size.
- program.o contains an unexpectedly large BSS segment of 306KB, why?
Not sure why shows up in program.o, but that might be the type_stack defined in pike_types.c. I guess it could be replaced that by something that resizes on demand.
There is a function lookup cache as well, that probably should be replaced with a mapping internally.
- cpp.o is 153KB vs. language.o being 131KB. It is rather unexpected
that the cpp module is larger than the actual language parser. Why don't we use yacc for the preprocessor too; or is it difficult to capture the rules in yacc for the preprocessor?
The preprocessor is included 3 times (once for each string width). A similar thing happens in sscanf (for all possible combinations of string widths).
There is also no point in including it three times, since you can happily use a slow version of cpp with one function for each string witdth. Per Hedbor worked on that a week ago, with very good results in triming down the size (just getting rid of all the inlined code does wonders in both size and speed). The code is however very britle, and in the end he ended up with strange bugs so he decided to start over at some later point, and do it in small incremental changes.