<div dir="ltr">Hello all!<div>Thank you for your excellent work on project Loom!</div><div><br></div><div>I have been for some time experimenting with defining "generator" based parsers in Java with Continuation. Recently, I moved on to performance testing using JMH. Below are numbers for a custom text line parser from this repository.<br><br><a href="https://github.com/pedrolamarao/generators-jvm" target="_blank">https://github.com/pedrolamarao/generators-jvm</a></div><div><br></div><div>In the below report:</div><div><br></div><div><ul><li>"reader" measures <font face="monospace">BufferedReader.readLine</font></li><li>"parser" measures my algorithm packaged in a SAX like, callback based parser</li><li>"generator" measures my algorithm packaged in a generator based parser</li></ul><div><br></div><div>Also, <font face="monospace">NewBenchmark</font> measures just creating the parser, and <font face="monospace">NextBenchmark</font> measures running the parser on a 10240 lines in-memory string.</div><div><br></div><div>These are numbers for benchmarking on my intel core i7 notebook, windows 11 notebook.</div><div><br></div><div><font face="monospace"># JMH version: 1.36<br># VM version: JDK 20, OpenJDK 64-Bit Server VM, 20+36<br># VM invoker: C:\Users\Pedro\.gradle\jdks\azul_systems__inc_-20-amd64-windows\zulu20.28.85-ca-jdk20.0.0-win_x64\bin\java.exe<br># VM options: --add-exports=java.base/jdk.internal.vm=ALL-UNNAMED --enable-preview<br># Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)<br># Warmup: 5 iterations, 10 s each<br># Measurement: 5 iterations, 10 s each<br># Timeout: 10 min per iteration<br># Threads: 1 thread, will synchronize iterations<br># Benchmark mode: Throughput, ops/time</font><br></div><div><br></div><div><font face="monospace">Benchmark                      Mode  Cnt     Score    Error  Units<br>NewBenchmark.generator        thrpt   25  3967,583 ± 48,073  ops/s<br>NewBenchmark.generator:·jfr   thrpt            NaN             ---<br>NewBenchmark.parser           thrpt   25  3987,014 ± 20,057  ops/s<br>NewBenchmark.parser:·jfr      thrpt            NaN             ---<br>NewBenchmark.reader           thrpt   25  3968,044 ± 24,480  ops/s<br>NewBenchmark.reader:·jfr      thrpt            NaN             ---<br>NextBenchmark.generator       thrpt   25   562,381 ±  6,218  ops/s<br>NextBenchmark.generator:·jfr  thrpt            NaN             ---<br>NextBenchmark.parser          thrpt   25  1439,171 ± 36,915  ops/s<br>NextBenchmark.parser:·jfr     thrpt            NaN             ---<br>NextBenchmark.reader          thrpt   25  2826,489 ± 23,449  ops/s<br>NextBenchmark.reader:·jfr     thrpt            NaN             ---</font><br></div><div><br></div><span><div><span>It appears that creating continuations is very fast!</span></div><div><span><br></span></div><div><span>JFR says that <font face="monospace">NextLineBenchmark.generators</font> spend a significant amount of time inside <font face="monospace">Continuation.yield</font>.</span></div><div><span><br></span></div><div>At this point, I'm not worried with the perfection of the line parser algorithm, but with the viability of defining generator libraries using Continuation. 

I am no expert and fully expect there to be some critical bug in my code, or in my understanding of how Continuation works. If someone could give me a hint, I would be very grateful!</div><div><span><br></span></div>-- </span><br><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div></div>