[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: sub-tree filtering proposals



Michael Walton wrote:

> Regarding code size of XPath: for interest and discussion's sake, I did a
> little footprint test using libxml2.
> 
> xpath.c seems to contain all the required processing, and is a fairly hefty
> source file at 324K.
> 
> Compiled and stripped it produces an object file of 88K. I tried gcc-i386 and
> gcc-ppc and both produce similar results.
> 
> Compressed (using mkcramfs for compressed ROM filesystem) it ends up at 36K.
> I haven't checked whether it incurs additional library requirements, etc. but
> I think it illustrates a point. 

Thank you very much, Michael!

So the difference in (compressed) size compared to an XPath subset or another
limited home-grown filtering mechanism is probably less than 25kB. I don't see
the point in saving this amount of memory compared to all the disadvantages
(enumerated in my last message) that a non-(full)-Xpath solution would cause.


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>