Archived issue #0029218
Application Framework - reading XML document calls LDOM parsing at least 3 times
Description
It seems, that reading XML document calls LDOM parser on entire file at least 3 times (2 times for probing/detecting format and 1 for actual reading).
It looks like a redundant overhead for using XML format efficiently.
It looks like a redundant overhead for using XML format efficiently.
Steps to reproduce
N/A.
Public activity
5 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: szy
Date: Wed Nov 22 12:54:33 2017 +0300
0029218: Application Framework - reading XML document calls LDOM parsing at least 3 times.
//Optimization only
[revision removed]
Detailed log of new commits:
Author: szy
Date: Wed Nov 22 12:54:33 2017 +0300
0029218: Application Framework - reading XML document calls LDOM parsing at least 3 times.
//Optimization only
Short explanation.
Indeed the Parser is called 3 times. But 2 times it is called just for format identification and only third time for real document parsing. First two calls are very short. They read just a single element (XML_START_ELEMENT) from the document header (defined by tag "document format") and cancel parsing.
There is no sufficient lost of performance during document reading.
Nevertheless the process may be a little bit optimized in next way.
There are some duplication caused by current persistence architecture logic.
Method "CanRetrieve" calls methods methods 'Format()' which calls Parser and
'ReaderFromFormat()'. Returned values (Format and Reader) in fact are not used inside. They are used only for check that it is feasible. Later during call of the method 'CDF_Application::Retrieve()' methods are called once again.
It is proposed to eliminate these calls in 'CanRetrieve' and keep only in 'Retrieve'. It is the simplest and the cheapest way which impacts only CDF_Application 'cxx'(see CR29218). Other approaches requires more sufficient modifications without sufficient benefit. Overlook it, please and give me your remarks.
Thanks.
Indeed the Parser is called 3 times. But 2 times it is called just for format identification and only third time for real document parsing. First two calls are very short. They read just a single element (XML_START_ELEMENT) from the document header (defined by tag "document format") and cancel parsing.
There is no sufficient lost of performance during document reading.
Nevertheless the process may be a little bit optimized in next way.
There are some duplication caused by current persistence architecture logic.
Method "CanRetrieve" calls methods methods 'Format()' which calls Parser and
'ReaderFromFormat()'. Returned values (Format and Reader) in fact are not used inside. They are used only for check that it is feasible. Later during call of the method 'CDF_Application::Retrieve()' methods are called once again.
It is proposed to eliminate these calls in 'CanRetrieve' and keep only in 'Retrieve'. It is the simplest and the cheapest way which impacts only CDF_Application 'cxx'(see CR29218). Other approaches requires more sufficient modifications without sufficient benefit. Overlook it, please and give me your remarks.
Thanks.
>There is no sufficient lost of performance during document reading.
OK, agree - there seems to be no performance issue due to multiple parsing - theWithoutRoot does the trick and only 3rd parsing takes considerable time (~ 10% of entire model reading; which depends on the model, of course).
Though slow input stream (like unpacking on the fly / DRM / slow hardware) might increase overhead to some degree.
OK, agree - there seems to be no performance issue due to multiple parsing - theWithoutRoot does the trick and only 3rd parsing takes considerable time (~ 10% of entire model reading; which depends on the model, of course).
Though slow input stream (like unpacking on the fly / DRM / slow hardware) might increase overhead to some degree.
Dear Commenter 1,
please close the issue since no fix is needed
please close the issue since no fix is needed
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records