Re: gobject-performance
- From: Stefan Kost <ensonic hora-obscura de>
- Cc: gtk-devel-list gnome org
- Subject: Re: gobject-performance
- Date: Thu, 08 Oct 2009 14:38:08 +0300
A. Walton schrieb:
> On Thu, Sep 24, 2009 at 9:37 AM, Benjamin Otte <otte gnome org> wrote:
>
>> Hi,
>>
>> I'd like to move the work done on the gobject-performance branch to
>> master now that 2.22.0 is out. It contains tremendous improvements for
>> threaded applications and even noticably speeds up non-threaded
>> performance. The patches on the branch have been developed, reviewed
>> and tested by at least Alex Larsson, Edward Hevery and me, so it
>> should be sufficiently reviewed.
>> I'd have liked to get Tim to review it, but he seems to be quite busy
>> now and IMO we threw enough eyes and CPU time at the issue to be sure
>> there is no regressions. (From the tests we added, I'd even say it's
>> more stable than master).
>>
>> I'd also like to get it merged while we're far away from the next
>> release, so it gets enough testing, as these changes are quite deep
>> down the stack and we want to find remaining issues with them before
>> we release the next stable.
>>
>> So can we merge the branch or is there anything that we should take
>> care of before?
>>
>
> Just have a small question on the subject: has anyone performed any
> library or application benchmarks to see how much this means in the
> real world and not just for the threaded microbenchmarks that you
> wrote? The non-threaded speedups are pretty impressive on their own,
> but it'd be nice to see what we could expect from e.g. GStreamer with
> these changes applied.
>
> Thanks,
> -A. Walton.
>
>
I have a quite complex use-case, that is loading and playing bigger
songs in buzztard. Its probably not a common use case, but there you can
measure the difference (values are best out of 3).
GST_DEBUG_NO_COLOR=1 GST_DEBUG="bt-core:3" ~/buzztard/bin/buzztard-cmd
2>&1 --command=play
--input-file=../share/buzztard/songs/buzz/Aehnatron-noPrimiFun.bmw |
grep async
before:
0:00:02.949420960 16963 0x8712538 INFO bt-core
song.c:692:bt_song_play: ->PAUSED needs async wait
0:00:06.205656656 16963 0x8712538 INFO bt-core
song.c:480:on_song_async_done: async state-change done
after:
0:00:02.760566012 17054 0x9e14538 INFO bt-core
song.c:692:bt_song_play: ->PAUSED needs async wait
0:00:06.065655074 17054 0x9e14538 INFO bt-core
song.c:480:on_song_async_done: async state-change done
number vary, but its like a 0.15 sec saving. That might not sound very
impressive, but then I see no point in not making the savings if we can.
As people have already invested time and energy to come up with the
changes, also the remaining changes should be merge to get more wider
testing.
Stefan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]