Idea: provide a way to cancel rendering ?

[maxandersen]

This is just an idea I got while trying to integrate asciidoctor into an eclipse builder and found that asciidoctor is pretty fast, but sometimes does take more than a few seconds to complete rendering my docs - and probably will take even longer when users will real big docs come along.

Would it be possible to somehow get programmatic feedback on how far asciidoctor is in its rendering ? and optimally be able to cancel rendering so it doesn't use unnecessary CPU ?

Usecase here is that I plan to add a builder to eclipse that will detect changes to files, start building when a resource (or directory with .adoc files) haven't been saved in a grace period (~1-5s) and then start the rendering - but if the user then starts saving the current running rendering is going to be useless and it would be great to just cancel it instead of having to wait for it to finish.

I can't just start a new rendering since the old one might overwrite files (I could of course overcome this by rendering to a separate file and just move it of to later but it would be nicer if I could just cancel the rendering.

[lordofthejars]

Are you calling render method or one of composed methods like renderDirectory, renderFiles, ....?

[LightGuard]

Max, I'm wondering if the performance you're seeing is jruby startup. I think the largest document we're rendering right now is the RichFaces documentation or the CDI spec and we're still doing both of those in a second or less with MRI (CRuby). — Sent from Mailbox for iPhone

On Mon, May 20, 2013 at 8:10 AM, Alex Soto notifications@github.com wrote:

Are you calling render method or one of composed methods like renderDirectory, renderFiles, ....?

Reply to this email directly or view it on GitHub: https://github.com/asciidoctor/asciidoctor-java-integration/issues/41#issuecomment-18149176

[lordofthejars]

Yes this was the other part I would like to comment you Max,, I suppose the creation of Asciidoctor interface (which contains the startup) is only executed once, most of all time is taken during startup phase. Also have you read (https://github.com/asciidoctor/asciidoctor-java-integration#optimization)[https://github.com/asciidoctor/asciidoctor-java-integration#optimization]

[mojavelinux]

Rendering a single document, even a very large one, should be exceptionally fast. However, we should think about the fact that as we offer a mechanism for plugins, external code could contribute to a delay. The only way for the Asciidoctor Java integration to know about the progress of a single doc is for an event signaling the progress to be added to Asciidoctor itself. We're exploring the idea of adding events as part of the extension mechanism, so this is a great candidate.

I certainly think it's reasonable for the Asciidoctor Java integration to be able to report progress when processing a batch. This is just a matter of adding an observer registry and notifying listeners before the batch and after each entry is processed.

Finally, most of the time is spent at JRuby start, as Jason and Alex alluded. Once JRuby is warmed up, it's even faster than MRI (CRuby). Exploring the best way to keep JRuby on the burner is an excellent opportunity to tighten integration w/ the IDE. This will either entail keeping a reference to the Asciidoctor instance, or allowing the IDE to supply a JRuby runtime instance to the library.

[lordofthejars]

I can provide a way the sent events from Java part of the kind processing 1 of 20 documents, 2 of 20, ... and so on, if you call the methods which receives a list of documents, but for now there is no way as Dan pointed out, to do the same for included files.

I like the idea about give the opportunity to the user to set the JRuby runtime instance into the library, I think that some problems with OSGi environment could also be fixed using this approach.