This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Robert Haschke
Recipients Robert Haschke, berker.peksag, guihome, serhiy.storchaka
Date 2016-06-17.16:07:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1466179637.6.0.609121661563.issue24424@psf.upfronthosting.co.za>
In-reply-to
Content
Indeed there is a small slow down for insertion at the beginning.
However, this is simply due to the extra function _index() and thus linear in the number of insertion operations.

My patch essentially boosts insertions before /any fixed/ node.
If this reference node changes between insertions (as in your "before first" example), there is no gain anymore.

Of course, this optimization comes at the cost of an additional integer per node. There is no free lunch!

I know, that there are other parsers (e.g. etree) available. However
changing my existing code base from minidom to etree will be a heavy change, which isn't easily accepted as well.

I think, my minidom patch is a clean and simple fix to a common performance issue. As it mostly effects 2.7, it should primarily go there ;-)
History
Date User Action Args
2016-06-17 16:07:17Robert Haschkesetrecipients: + Robert Haschke, berker.peksag, serhiy.storchaka, guihome
2016-06-17 16:07:17Robert Haschkesetmessageid: <1466179637.6.0.609121661563.issue24424@psf.upfronthosting.co.za>
2016-06-17 16:07:17Robert Haschkelinkissue24424 messages
2016-06-17 16:07:17Robert Haschkecreate