Christian,
Thanks for the info on PID3 lists when using the PreParser, I was wondering
what your thoughts on doing the following to get around the PID3 list.
I use the getFields() of preParser to get more PID 3 repeats than we could
possibly have. In our case, 250 was determined to be quite adequate to
cover all the possible patient identifiers (base on the number of
facilities in our system multiplied by 2, then rounded up to nearest 10)
Even when getting 250 fields (most of which return null) we are still
massively quicker than a full parse.
Can you think of any issues when taking this approach?
Cheers,
-Mike
On 30 June 2017 at 15:11, Christian Ohr <christian....@gmail.com> wrote:
> No,
>
> going into the details of the message requires fully parsing it to the
> internal model. The normal parser also cares about all the variability and
> character escaping rules defined in HL7v2, that’s why it takes more time
> and resources.
>
>
>
> Christian
>
>
>
>
>
> *Von: *Mike Mills <m...@themills.id.au>
> *Gesendet: *Freitag, 30. Juni 2017 03:59
> *An: *Christian Ohr <christian....@gmail.com>
> *Betreff: *Re: [HAPI-devel] Hapi parse performance.
>
>
>
> Christian,
>
>
>
> Is there a way to deal with PID 3 lists when using the PreParser.
>
>
>
> There does not seem to be a way to get a count of the list, nor a way to
> return the whole pid3 value.
>
>
>
> Any suggestions?
>
>
>
> Kind regards
>
>
>
> Mike
>
>
>
> On 30 Jun. 2017 4:38 am, "Christian Ohr" <christian....@gmail.com> wrote:
>
> Hi Mike,
>
> check if http://hl7api.sourceforge.net/base/apidocs/ca/uhn/hl7v2/
> preparser/PreParser.html would help in your case, when you just need to
> extract a single field.
>
> cheers
> Christian
>
> Am 29.06.2017 um 03:17 schrieb Mike Mills:
>
> Hi,
>
>
>
> Are the any efforts being made to improve the performance of parsing an
> hl7 message?
>
>
>
> I am considering dropping parsing of messages using hapi because of the
> CPU load and memory requirements.
>
>
>
> It seems like Hapi parses like a DOM parser as it goes though the entire
> message.
>
>
>
> It would be good if the message was lazily parsed so that no parsing
> occurs until a teaser.get call is made, or an accessor called on the
> concrete message object returned from parse(). When the terser path is
> executed only the required segment/group/field/sub fields are processed to
> retrieve the desired value.
>
>
>
> That way, if we wanted just the MSH9-2 the copy expense of parsing an
> entire message is not required.
>
>
>
> My initial performance testing indicates that the JVM dropped from 10% CPU
> usage with Hapi to 3% CPU usage when using string.split().
>
>
>
> Are there efforts being made to address the performance of Hapi?
>
>
>
> Kind regards.
>
>
>
> Mike
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
>
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
>
> Hl7api-devel mailing list
>
> Hl7api-devel@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
