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. > > 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. -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
