28 Feb
2011
28 Feb
'11
5:24 p.m.
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