Parser very slow with repeated parse calls
andrewchambers opened this issue · 3 comments
andrewchambers commented
bench.peg:
%prefix "asm"
%earlyheader {
typedef struct {int x; int y; int z;} Parsev;
}
%value "Parsev"
# Uncomment for 10X speed.
# file <- line+
line <- s:stmt eol
/ eol
/ .
stmt <- d:directive
/ i:instr
/ l:label
directive <- ".glob" "o"? "l" ws i:ident
/ ".data"
/ ".text"
/ ".balign" ws n:number
/ ".byte" ws n:number
label <- i:ident ':'
instr <- "nop"
/ "leave"
/ "ret"
/ i:jmp
/ i:add
jmp <- "jmp" ws i:ident
add <- "add" 'q'? ws s:m ws? ',' ws? d:r64
/ "add" 'q'? ws s:imm ws? ',' ws? d:r64
/ "add" 'q'? ws s:r64 ws? ',' ws? d:m
/ "add" 'q'? ws s:r64 ws? ',' ws? d:r64
/ "addq" ws s:imm ws? ',' ws? d:m
m <- '(' ws? r:r64 ws? ')'
/ <'-'?[0-9]+> ws? '(' ws? r:r64 ws? ')'
/ i:ident ws? '(' ws? r:r64 ws? ')'
r64 <- "%rax"
/ "%rcx"
/ "%rdx"
/ "%rbx"
/ "%rsp"
/ "%rbp"
/ "%rsi"
/ "%rdi"
/ "%r8"
/ "%r9"
/ "%r10"
/ "%r11"
/ "%r12"
/ "%r13"
/ "%r14"
/ "%r15"
imm <- '$' i:ident
/ '$' <'-'?[0-9]+>
ident <- <[_a-zA-Z][_a-zA-Z0-9]*>
number <- <'-'?[0-9]+>
ws <- [ \t]+
eol <- ws? ("\n" / (! .))
%%
int main() {
asm_context_t *ctx = asm_create(NULL);
while (asm_parse(ctx, NULL));
asm_destroy(ctx);
return 0;
}
bench.txt:
for i in `seq 100000`; do echo "addq %rax, (%rax)" >> bench.txt ; done
First run, one parse call per line:
$ ./packcc ./bench.peg && clang -O2 -g bench.c -o bench
$ time ./bench < bench.txt
real 1m22.178s
user 1m21.425s
sys 0m0.428s
Now uncomment the file <- line+
part of the benchmark:
$ ./packcc ./bench.peg && clang -O2 -g bench.c -o bench
$ time ./bench < bench.txt
real 0m1.221s
user 0m1.026s
sys 0m0.192s
If I benchmark the first case, I find the majority of work is memmove of the internal packcc arrays, my intuition is this extra work does not seem correct.
arithy commented
If I benchmark the first case, I find the majority of work is memmove of the internal packcc arrays, my intuition is this extra work does not seem correct.
You are right. The main cause is frequent call of memmove()
.
I have pushed the fixed version. Now, the both test cases show almost the same performance.
Please try it.
andrewchambers commented
thank you.