1 Mar
2011
1 Mar
'11
2 p.m.
2011/3/1 David Robillard <d(a)drobilla.net>et>:
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
On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi
wrote:
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.
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.