Journal activity profiling

[Tomeu Vizoso]

On Thu, Aug 14, 2008 at 12:38 AM, Michael Stone <michael at laptop.org> wrote:
> On Wed, Aug 13, 2008 at 06:02:49PM +0200, Tomeu Vizoso wrote:
>>
>> On Wed, Aug 13, 2008 at 5:20 PM, riccardo <riccardo.lucchese at gmail.com>
>> wrote:
>>>
>>> On Wed, 2008-08-13 at 12:13 +0200, Tomeu Vizoso wrote:
>>>>
>>>> On Tue, Aug 12, 2008 at 12:10 PM, riccardo <riccardo.lucchese at gmail.com>
>>>> wrote:
>>>> > Testcase:
>>>> > Fill the journal with hundreds of entries and automate the
>>>> > GtkScrollWindow in the journal to scroll one entry at time on a
>>>> > timeout.
>>>> >
>>>> > Build: joyride-2281
>>>
>>>> > The test runs slower when the journal has more entries than when it's
>>>> > almost empty, why is it ?
>>>>
>>>> Not sure, perhaps because there are more entries in the DS so the
>>>> query takes more time? Can you check?
>>>
>>> I cannot reproduce it by just adding more objects to the DS. I think I
>>> had `particular' objs in the journal when I saw it: ie. if I only
>>> push .xo packages to the DS the journal scrolls very slowly (after
>>> activities get installed)
>>
>> Yeah, we need to read the bundle id and version number from inside the
>> bundle :/
>
> Then cache them. You can maintain the cache with inotify, mtime,
> regenerate on boot, etc. Git and make both know how to deal with this.
> Why don't we?

Because we are waiting your patches ;)

Seriously, we are analyzing performance right now so we know better
what is worth caching. Once we know that, someone needs to find time
to do it.

> Also, why would it take any significant time to read the bundle_id &
> version? Wait -- because we used a format for that must be parsed
> instead of splitting the fields into separate files?

You mean activity.info? I don't think that's the biggest issue,
Riccardo might know better.

Regards,

Tomeu