Latest parser span feature caused performance regression

[ChAoSUnItY]

After several benchmarking tests on before-span-mark, after-span-mark, classfile-rs, classfile-parser, using the same sets of test class files provided in Kapi, the results are:

before-span-mark:

after-span-mark:

classfile-rs:

classfile-parser:

Why ka-pi is slower?

The above test results shows that:

1. Compare to imperative parser, which is the parser technique classfile-rs uses, parser combinator is slower (inline probably will not help very much).
2. Span marks generally caused performance regression, and its use case is very limited.

Worth notice that ka-pi's annotation attribute parser is more performant than classfile-parser, even though classfile-parser haven't implemented annotation attribute parsing yet.

Conclusion

In general, span marking is a bad idea both to users who don't need it and users who needs performance, also, nom is causing quite much performance regression to parser.

To resolve this, ka-pi needs to revert back to before span-mark merges into main branch, also, a rewrite of imperative parser without span-marking is required.

[ChAoSUnItY]

Edit:
It seems indeed reader improves a little bit of performance, but overall, the regression which is causing here is due to the additional parsing phases e.g. attribute infos.

To make it clear, I'll implement parsing option allows user to parse attribute info or not to makes the benchmark result relatively fair.