|Re: [wtp-dev] JSDT Parser|
On 11 Mar 2016, at 11:34, Eugene Melekhov wrote:
Gorkem,Thanks for prompt reply. I read your post about benchmarking with pleasure. I've never heard about Shift parser and it looks very promising. I took a quick glimpse at sources and imho they are really smart, neat and "clean" :-). Great job.BTW, they implemented location info, so the only missing part is error recovery / tolerant parsing. Speaking of which, it seems that with their two-phase parser recovery is only required at syntax level. "Semantic/Early errors" are handled separately, which on the one hand probably makes recovery easier to implement and on the other hand gives clientsome freedom to use second pass only if needed, and speed of course...I ran your benchmarks (w/o node. I didn't want to bother with configuring node benchmark properly on my Windows box).Below are my results: # Run complete. Total time: 01:26:54 Benchmark Mode Cnt Score Error Units AcornWithJ2V8.testAngular125 thrpt 200 10,176 ? 0,045 ops/s AcornWithJ2V8.testJQM142 thrpt 200 7,755 ? 0,023 ops/s AcornWithNashorn.testAngular125 thrpt 200 11,398 ? 0,310 ops/s AcornWithNashorn.testJQM142 thrpt 200 8,793 ? 0,257 ops/s EsprimaWithJ2V8.testAngular125 thrpt 200 11,393 ? 0,135 ops/s EsprimaWithJ2V8.testJQM142 thrpt 200 9,432 ? 0,029 ops/s EsprimaWithNashorn.testAngular125 thrpt 200 15,459 ? 0,130 ops/s EsprimaWithNashorn.testJQM142 thrpt 200 15,223 ? 0,110 ops/s NashornParser.testAngular125 thrpt 200 41,306 ? 0,208 ops/s NashornParser.testJQM142 thrpt 200 37,744 ? 0,104 ops/s ShiftJava.testAngular125 thrpt 200 74,734 ? 0,203 ops/s ShiftJava.testJQM142 thrpt 200 76,934 ? 0,413 ops/sAs you might notice I've added NashornParser (native JVM) test (sample borrowed from Nashorn sources). And it performsquite well, not as good as Shift, but not bad.
This is excellent can you send a pull request to that repo so that we have those tests always handy.
Yes, shift was my early favourite as well, however not getting any response to my requests and seeing shift.js being active while shift.java was dormant did not really help. Also shift.java (and its AST model) is not really adopted by anyone else. At the end, we were not looking for a parser to maintain ourselves ( we had that already). But I agree, we can switch to shift.java if we can feel more confident about the future of the project.So, according to the benchmarks Esprima with Nashorn and Nashorn "native JVM" parser are good options, but in the long run I'd prefer to use Shift because it's fast, it's nice Java etc. It might worth trying to add error recovery to it ifit's not that hard....
I've managed to obtain, compile, run/test latest code that you've mentioned; I have more or less normal working configuration and can do something useful. So, what would you suggest to look at? Some small/relatively easy task that would allow me to get acquainted with code and bring some value? I thought that something like unit tests for particularparser/ast related parts would be a good start. What do you think?
That would be fantastic and I have the perfect candidate. Please take a look at . It is a small enough task but will
get you familiar with the AST quickly :)  > https://bugs.eclipse.org/bugs/show_bug.cgi?id=489450
Back to the top