[gstreamer] Enabling binary cache (instead of the xml one)

[gstreamer] Enabling binary cache (instead of the xml one)

[Holger Freyther]

Hey Guys,

I wonder if we have ever considered in using the experimental gstreamer 
feature to build it with "--enable-binary-registry".

This is not changing the way the registry is working, the result is simply 
stored in binary and not xml. This avoids parsing on start.

For devices like the neo (with incredible slow flash speed) avoiding stating 
all plugins would (changing the way the registry is working) would be a lot 
better...

what do you think? Risk and use an experimental feature (it is using mmap so 
the risk of SIGBUS is there)

	z.



Results of micro benchmark on my neo:

Binary cache:

# Building cache
Total count: 119 plugins, 351 features
real    0m 12.36s
user    0m 5.71s
sys 0m 5.72s

# Cached
Total count: 119 plugins, 351 features
real    0m 1.74s
user    0m 1.03s
sys 0m 0.35s


XML Cache:
# Building cache
Total count: 119 plugins, 351 features
real    0m 16.42s
user    0m 6.94s
sys 0m 9.19s


# Cached
Total count: 119 plugins, 351 features
real    0m 1.87s
user    0m 1.28s
sys 0m 0.41s
root@om-gta02:~# 

Re: [gstreamer] Enabling binary cache (instead of the xml one)

[Leon Woestenberg]

Hey,

On Sat, Nov 15, 2008 at 12:04 AM, Holger Freyther <zecke@selfish.org> wrote:
> I wonder if we have ever considered in using the experimental gstreamer
> feature to build it with "--enable-binary-registry".
>
Good find.

> what do you think? Risk and use an experimental feature (it is using mmap so
> the risk of SIGBUS is there)
>
Should work, or be fixed elsewhere(tm).

+1

Regards,
-- 
Leon

Re: [gstreamer] Enabling binary cache (instead of the xml one)

[Koen Kooi]

On 15-11-08 00:04, Holger Freyther wrote:
> Hey Guys,
>
> I wonder if we have ever considered in using the experimental gstreamer
> feature to build it with "--enable-binary-registry".
>
> This is not changing the way the registry is working, the result is simply
> stored in binary and not xml. This avoids parsing on start.
>
> For devices like the neo (with incredible slow flash speed) avoiding stating
> all plugins would (changing the way the registry is working) would be a lot
> better...
>
> what do you think? Risk and use an experimental feature (it is using mmap so
> the risk of SIGBUS is there)

Is it using read-only mmap or read-write mmap? If it's the latter then 
people using jffs2 are out of luck :(

regards,

Koen

>
> 	z.
>
>
>
> Results of micro benchmark on my neo:
>
> Binary cache:
>
> # Building cache
> Total count: 119 plugins, 351 features
> real    0m 12.36s
> user    0m 5.71s
> sys 0m 5.72s
>
> # Cached
> Total count: 119 plugins, 351 features
> real    0m 1.74s
> user    0m 1.03s
> sys 0m 0.35s
>
>
> XML Cache:
> # Building cache
> Total count: 119 plugins, 351 features
> real    0m 16.42s
> user    0m 6.94s
> sys 0m 9.19s
>
>
> # Cached
> Total count: 119 plugins, 351 features
> real    0m 1.87s
> user    0m 1.28s
> sys 0m 0.41s
> root@om-gta02:~#

Re: [gstreamer] Enabling binary cache (instead of the xml one)

[Michael 'Mickey' Lauer]

Amazing find.

 +1


-- 
:M:

Re: [gstreamer] Enabling binary cache (instead of the xml one)

[Phil Blundell]

On Sat, 2008-11-15 at 00:04 +0100, Holger Freyther wrote:
> Binary cache:
> 
> # Cached
> Total count: 119 plugins, 351 features
> real    0m 1.74s
> 
> XML Cache:
>
> # Cached
> Total count: 119 plugins, 351 features
> real    0m 1.87s

So, if I'm reading that right, the binary cache gives you a startup time
improvement (assuming a hot cache) of about 0.13 seconds.  It sounds
like there are probably bigger savings to be had by, as you suggest,
eliminating the stat() of all plugins and/or reducing the number of
unnecessarily installed plugins; it seems fairly unlikely that many
applications are really using all 119 of those.

That said though, "every little helps" and this certainly seems like it
would be a worthwhile improvement.  There's nothing particularly scary
about the use of mmap().

p.