On Thu, 8 May 2014, Stephen R. van den Berg wrote:
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.
- 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). One other culprit for code size is sprintf, due to the use of huge macros for slow paths. There are this and other places where reducing the code size by de-inlining would also help performance on big cpus (or at least not make it slower). arne p.s. nm -S pike | cut -d ' ' -f 2- | sort -r | less
