You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A lot of this indirection adds a lot of overhead. so how this is working at the moment is there an an implementation from iXmlDocument to cXmlDocumentTiny, but the data has to be repackaged to fit this abstraction. There is quite a bit of overhead in moving the data like this since its loaded from disk then copied again.
using a std::map to store string pairs is overkill since the size of the data doesn't warrant all the overhead of the data structure. A linked list for children will cause a lot of fetching from CPU to main memory.
usage is a closed set where the usage is only ever one xml parsing library, there isn't really a need to build an abstraction that might potentially support another xml parsing library. I think there is an argument for some kind of reflection API to better allow serializing and de serializing entities, what that entails I'm not so sure.
notes
fastXML does use a linked listed structure but the data is allocated to a memory pool so memory maintains locality.
we should see a pretty decent performance boost getting rid of these abstractions and if the time arises to use something else it shouldn't be too difficult to transition to another library. usage is somewhat self contained so it can easily be done in steps
At the end we should get rid of XmlDocumentTiny/XmlDocument and tinyXML.
The text was updated successfully, but these errors were encountered:
Description
A lot of this indirection adds a lot of overhead. so how this is working at the moment is there an an implementation from iXmlDocument to cXmlDocumentTiny, but the data has to be repackaged to fit this abstraction. There is quite a bit of overhead in moving the data like this since its loaded from disk then copied again.
using a std::map to store string pairs is overkill since the size of the data doesn't warrant all the overhead of the data structure. A linked list for children will cause a lot of fetching from CPU to main memory.
usage is a closed set where the usage is only ever one xml parsing library, there isn't really a need to build an abstraction that might potentially support another xml parsing library. I think there is an argument for some kind of reflection API to better allow serializing and de serializing entities, what that entails I'm not so sure.
notes
The text was updated successfully, but these errors were encountered: