[fpc-devel] Want to remove AVL_Tree from DOM

[Marco van de Voort]

In our previous episode, Sergei Gorelkin said:
> 
> I want to remove the avl_tree-related stuff from DOM unit. The reasons are:
> 
> 1) It is targeted to optimize one particular type of documents, "configs",
>     that require all node names within a single parent to be unique
>     (strictly speaking, this isn't xml, it is more like ini-files or
>     Windows registry).

I use the config stuff very heavily in my Delphi app at work (based on the
lazarus one), and various little utils in FPC that communicate with it.

Currently the lazarus variant, but had planned to move
to the FPC variant as soon as unicodestring would have been introduced.

I don't make that much use of the fact that it is avltree inside though, but
I _really_ would like to keep the current interface, and not add additional
requirements, since it is used fairly finely grained in my app, and making
changes to how a node is retrieved is not an option. (opening/closing code
is)

> 3) It is known to have yet unresolved multithreading-related problems (Mantis 12984).
 
(this is very minor afaik. The actual problem was fixed, and what is left is
more the bugreporters wishlist to have one nodemgr over multiple threads, at
the expense of making everything locked)

> 
> 2) The new xmlconf unit has the OpenKey/CloseKey methods which improve
>     performance by limiting the search range to a specific element.
>     Utilizing this feature, however, need modifications to the user code
>     so it actually calls OpenKey/CloseKey (note that is works perfectly
>     without the modifications, it's only the matter of performance).

That should be enough. Performance is less of an item.

> 3) It is possible to create even faster xmlconfig class, consisting of
>     TXMLDocument + THashTable, offering O(1) access to any element. The
>     problem is that it is somewhat mutually exclusive to the previous
>     solution (OpenKey/CloseKey).

I prefer that one.
 
> 4) Finally, the xpath, being sufficiently mature, can supersede it all and
>     provide a much more powerful solution.

This is no help to me, i'm committed to the current interface
 
short summary:
- need the current interface very badly to be backwards compat, if I (and
   Lazarus) are ever migrating to a FCL one. Changes to the interface
   not really an option, then I'd stick to my ancient lazarus version forever.
- I'm talking about the lazarus version atm, afaik that one has been
  optimized in the past because the FCL version was slow.
- Don't like openkey/closekey much. On the other hand, my XML config
  loading/saving is not that much performance dependant, so if it remains
  working without openkey/closekey, and it is not too bad, it is fine. (I
  must be able to load/store a 10-40kb file in sub 50ms, but that should be
  doable).