2011/3/1 David Robillard <[email protected]>: > On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote: >> Hi! >> >> On 02/26/2011 09:08 PM, David Robillard wrote: >> >> > Fair enough. The sum of all installed LV2 data loaded into a data >> > structure can be large, though. My new implementation is still not quite >> > optimal, though: >> >> [...] >> >> > On Android it's probably not an issue though, as you say. For other >> > embedded situations it would be nice to have absolutely minimal space >> > overhead on top of the actual data itself... plus it's fun :) >> >> It makes sense indeed to reduce memory usage, but reading the above, I get a >> feeling like parsing the metadata of a typical plugin set won't exceed a few >> Kb >> of RAM. >> >> To give you an idea, on a rather old device such as the HTC Magic, you have >> 288Mb of RAM, and when an app is in the foreground you can safely use quite a >> lot of memory. >> >> There could more constrained embedded situations where plugins are needed, >> although I can't really think about any real-world example ATM. > > I will need to make a "load all LV2 data and do nothing" program to > benchmark how much space is used by loading all LV2 stuff. I suspect it > will be a figure workable within 288MB of RAM, but ideally should be > smaller since apps have other things to store, especially when audio is > involved.
IIRC, my Turtle parser/in-memory graph store, had roughly a < 6x overhead over the actual amount of data, that on my laptop is around 1 MB (excluding dynamic manifests). I bet that we are already able to stay below 32 MB with lots and lots of plugins around. However, I think the actual RAM usage is more dependent on loaded plugin libraries and plugin instances in hosts that allow you to load more than a small bunch of them. And that cannot be avoided AFAIK. In this regard, SLV2 is already showing good behavior in loading metadata on demand. >> > Fair enough. It seems the libraries involved can be built to be well >> > under 100k with -Os and such, but I have no idea how 64-bit shared >> > library code compares to static android code in terms of size. I'm all >> > for contributions that shave a bit of space, but everything seems pretty >> > good to me now (glib aside). >> >> Once you remove the glib dep, I should be able to tell you what size I get >> when >> compiling with the Android NDK. I have checked again, and 100Kb is good in my >> case. FYI, APK packaging uses zip compression. > > I would guess it will be at the very least a month before this happens, > unless somebody steps up to do it. The relevant SLV2 release > announcement will mention the glib removal. Are you planning to remove it in the next release? Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
