Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

From: Stefano D'Angelo <zanga.mail@email-addr-hidden>
Date: Tue Mar 01 2011 - 15:00:35 EET

2011/3/1 David Robillard <d@email-addr-hidden>:
> 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.

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.

>> > 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.

Are you planning to remove it in the next release?

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Mar 1 16:15:02 2011

This archive was generated by hypermail 2.1.8 : Tue Mar 01 2011 - 16:15:02 EET