1 Mar
2011
1 Mar
'11
12:18 a.m.
On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote:
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
Hi!
On 02/26/2011 09:08 PM, David Robillard wrote:
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. 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.