Something is horribly unoptimized when compiling mappings. I did some data processing and wrote out the resulting mapping with sprintf %O into a text file, resulting in some 40,000 entries. I then created a file like this
mapping m= #include "stat.txt" ;
void main() { }
and started it. Since it took a long while to execute I wrote this while waiting
void main() { mapping m = ([]); foreach(Stdio.File("stat.txt")->line_iterator();;string line) { int a,b; if( sscanf(line, "%*s%d: %d", a,b)==3 ) m[a] += b; } }
which ended up taking
real 0m0.222s user 0m0.208s sys 0m0.008s
I have now stopped the first program, which didn't yet terminate. It looked like this just before I stopped it.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7962 nilsson 20 0 1264m 1.2g 792 R 100 61.8 974:54.12 pike
Sounds like the parse tree is reduced from the right instead of the left.
Sounds like the parse tree is reduced from the right instead of the left.
The grammar looks properly left-recursive to me:
| m_expr_list: { $$=0; } | | m_expr_list2 optional_comma | ; | | m_expr_list2: assoc_pair | | m_expr_list2 ',' assoc_pair | { | if ($3) { | $$=mknode(F_ARG_LIST,$1,$3); | } else { | /* Error in assoc_pair */ | $$=$1; | } | } | | m_expr_list2 ',' error | ; | | assoc_pair: expr0 expected_colon expr0 | { | $$=mknode(F_ARG_LIST,$1,$3); | } | | expr0 expected_colon error { free_node($1); $$=0; } | ;
My guess is that the problem lies somewhere in the optimizer or code-generator.
Speaking of mapping constants, I recently fixed this bug in refdoc/presentation/make_html.pike:
mapping lay = ([ ... "dochead" : "<dt>", "_dochead" : "</dt>\n", ... "dochead" : "\n<dt style='font-family: sans-serif'>", "_dochead" : "</dt>\n", ... ]);
Ought to give a warning, I think. Or maybe even an error.
If you do the equivalent in C you don't even get a warning, so I think an error would be a bit overmuch. I'm fine with adding a warning for it.
I can't think of any obvious equivalent to a mapping initialization in C. What do you mean?
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
Something is horribly unoptimized when compiling mappings. I did some data processing and wrote out the resulting mapping with sprintf %O into a text file, resulting in some 40,000 entries. I then created a file like this
A similar thing happens when including a large file containing arrays.
The following program takes about two minutes to execute and uses about 500 megabytes of memory with http://hancke.name/pike/l2.i (18 meg):
#include "l2.i" void main() { }
Manual extraction with lots of sscanf takes about two seconds.
The lesson I learned from that is not to include large amounts of data as code.
pike-devel@lists.lysator.liu.se