Hi All,

  Important note I forgot to mention, replacing old cookcc based parser

introduces API incompatibility, because JSONParser, Parser and JSONParserImpl

were public classes in DMR 1.3.0.Final.

  I optimized DOM API write process in 'compact' mode as mentioned in previous mail.

DMR 1.4.0.Beta is faster on all benchmarks comparing to DMR 1.3.0.Final.

Concretely:

 * Writing small DMR structures in DMR format is 1,3 times faster with DOM API
 * Writing small DMR structures in JSON format is 1,4 times faster with DOM API
 * Writing small DMR structures in DMR format is 2,5 times faster with streaming API
 * Writing small DMR structures in JSON format is 2,6 times faster with streaming API
 * Reading small DMR structures in DMR format is 4 times faster with DOM API
 * Reading small DMR structures in JSON format is 3,7 times faster with DOM API
 * Reading small DMR structures in DMR format is 4,9 times faster with Streaming API
 * Reading small DMR structures in JSON format is 4,4 times faster with Streaming API 

 * Reading big DMR documents in DMR format is 5,7 times faster with DOM API
 * Reading big DMR documents in JSON format is 6,4 times faster with DOM API
 * Reading big DMR documents in DMR format is 7,4 times faster with Streaming API
 * Reading big DMR documents in JSON format is 8,8 times faster with Streaming API

Hi All,

The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - see attachment.

The idea of this new feature grew up while I was working on DMR-9 issue [2].

In short the news in upcoming JBoss DMR 1.4.0 are:
 * it will be compilable on JDK8 and above
 * it will be 100% backward compatible on binary level with previous version
 * it replaces old cookcc based parser with new one based on DMR Streaming API
 * DMR parsing will be times faster with old model based API
 * new DMR streaming API is highly memory efficient and really very fast

One example on how to use new DMR streaming API can be seen here [3].

I believe this new DMR Streaming API will become very handy for many of us
because it opens new opportunities to decrease memory and CPU usage in our core.

At the moment in current prototype [4] I didn't touch DMR object model writing yet
because new DMR Streaming API does not (and most probably will not) support pretty print feature
(because of its focus on speed and efficiency).
But I'm considering I might fix the object model writing flow when pretty print is off.
Fixing it would speed it up significantly. Any objections?

As a final note today I run few benchmarks (see attachments).
Here are some outcomes from benchmark results in short:
 * Writing small DMR structures in DMR format is 2,4 times faster with new DMR streaming API
 * Writing small DMR structures in JSON format is 2,6 times faster with new DMR streaming API
 * Reading small DMR structures in DMR format is 3,9 times faster with old DMR object model API
 * Reading small DMR structures in JSON format is 3,7 times faster with old DMR object model API
 * Reading small DMR structures in DMR format is 5 times faster with new DMR streaming API
 * Reading small DMR structures in JSON format is 4,4 times faster with new DMR streaming API
 * Reading big DMR structures in DMR format is 5,2 times faster with old DMR object model API
 * Reading big DMR structures in JSON format is 6 times faster with old DMR object model API
 * Reading big DMR structures in DMR format is 7,6 times faster with new DMR streaming API
 * Reading big DMR structures in JSON format is 8,8 times faster with new DMR streaming API

PS: Hopefully new DMR streaming API will seamlessly integrate with GWT (used in our console).

[1] https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream
[2] https://issues.jboss.org/browse/DMR-9
[3] https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java
[4] https://github.com/ropalka/jboss-dmr/commits/DMR-9

Regards,

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Richard Opalka
Principal Software Engineer
JBoss by Red Hat
Mobile: +420 731 186 942