[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/>