From 28M to 2.7M
As some of you already know, I've been working on a simple AV-specific control-point as part of gupnp-tools. While at it, I've been trying to keep the UPnP AV parts as separate and generic as possible so that they could be move to a separate library later on. One of the first things that everyone wanted to create a nice wrapper for is the ugly DIDL-Lite. Jorn tried his best to convince me and others to not create a GObject for representing each DIDL-Lite object but I didn't listen and ended-up writing a very resource hungry API. To see what i mean, please look at memory usage of gupnp-av-cp after populating it's treeview with the content hierarchy exported by coherence:
I was quite sure that most of this 28M is taken by xmlDoc and I was right. Now that I have got rid of xmlDoc usage and replaced the gobjects with an API to deal with xmlNodes, here is how the memory usage looks like:
For people who are curious on how this simple AV control-point would look like, here is a screenshot:
One reason why the development of GUPnP might seem much slower compared to that of other UPnP projects out there is that we (especially Jorn) are trying our best to provide a nice and simple API while making sure that no part of the project is resource hungry as we are targeting embedded systems where saving bytes is more impotant than providing lots of features. Jorn already have a plan and some half-baked code for the handling of DIDL-Lite xml and contents on the server-side (ContentDirectory implementation) without wasting lots of memory and CPU.
I was quite sure that most of this 28M is taken by xmlDoc and I was right. Now that I have got rid of xmlDoc usage and replaced the gobjects with an API to deal with xmlNodes, here is how the memory usage looks like:
For people who are curious on how this simple AV control-point would look like, here is a screenshot:
One reason why the development of GUPnP might seem much slower compared to that of other UPnP projects out there is that we (especially Jorn) are trying our best to provide a nice and simple API while making sure that no part of the project is resource hungry as we are targeting embedded systems where saving bytes is more impotant than providing lots of features. Jorn already have a plan and some half-baked code for the handling of DIDL-Lite xml and contents on the server-side (ContentDirectory implementation) without wasting lots of memory and CPU.
Comments