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.
Finally attached are up2date benchmarks against PR [1].
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
[1]
https://github.com/jbossas/jboss-dmr/pull/20
On 06/13/2016 11:48 PM, Richard Opalka wrote:
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/d...
[2]
https://issues.jboss.org/browse/DMR-9
[3]
https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/d...
[4]
https://github.com/ropalka/jboss-dmr/commits/DMR-9
Regards,
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)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