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