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, -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 06/14/2016 06:01 AM, Rostislav Svoboda wrote: >> Hi All, >> >> The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - >> see attachment. > Will be DMR 1.4.z included in WF 11 or also in next EAP 7 release? Most likely both. >> 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 > Nice results in attached spreadsheets. > >> 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? > I think pretty print feature is need, at least in CLI for stuff like ':read-resource(recursive=true)' This is still done by the DOM-style API, correct Richard?

(eom) > Rostislav > >> 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, >> >> -- >> Richard Opalka >> Principal Software Engineer >> JBoss by Red Hat >> Mobile: +420 731 186 942 >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

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 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 06/17/2016 09:55 AM, Brian Stansberry wrote: > On 6/16/16 3:28 PM, Richard Opalka wrote: >> 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. >> Can we keep these around and @Deprecate them? > For Parser and JSONParser I mean the actual current generated classes. > If generating them is an issue I see no need to keep doing it. > Deleting them isn't the end of the world but if it is simple to keep > them it's nice to do a deprecate and then remove later. It may be possible to create compatible stubs.