On Tue, Feb 19, 2013 at 03:27:02AM +0100, Lennart Poettering wrote:
> Well, to be fair: if an app just prints a "couple of log messages", then
> the functions you point out should hardly matter... Optimize inner
> loops, not just the stuff that happens to be called a "couple of"
> times...
I agree, with a "couple of log messages" journald shouldn't be anywhere
the CPU usage it is. Now my instruments are primitive, 'cross' perf
appears to be not implemented yet (another thing to put in the backlog) but
with what I have the _int_malloc sounds plausible. I spent years optimizing
WebKit and getting rid off a malloc was always a measurable improvement.
> No, the purpose of journald is not to allocate memory. It's primary
> purpose is actually to collect sarcastic comments by people. We thrive
> on that...
And it is called journald so you can keep track of the comments? ;)
> Does this mean I will now optimize them all away for you? No, not
> really, I don't even have the appropriate hardware to profile this. Does
> this mean I will merge good patches that optimize this? Hell, yes!
It works both ways. If I'm going to spend a significant amount of my time
to make journald usable on embedded hardware (right now my product doesn't
really need it) I want to have some kind of commitment that while I cut back
on dynamic allocations not a ton of new ones get introduced at the same time.
Just to be clear, when I talk about cutting back dynamic allocations I don't
mean introducing char foo[SHOULD_BE_BIG_ENOUGH_BUT_IS_NOT] but to be a bit
more clever about the usage. E.g. have a 'scratch' string, avoid reallocs
in steps of one, etc.
cheers
holger
PS: I thought Nokia hooked you up with a N900 or such?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
