On Tue, 19.02.13 19:21, Holger Hans Peter Freyther (hol...@freyther.de) wrote:
> > 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.
Well, I am not going to give you a blanket promise that I will merge any
patch you send us, but yes, we will consider every patch and merge the
good stuff, and we will try to avoid making things worse again. I mean,
the code in question otherwise is not really code to refactor anyway in
my eyes, so I think there's not much risk to fuck this up again
anyways...
Also, adding a comment to dispatch_message_real() saying:
/* Hey, this code is run for each log line, consider it an inner
loop function, so minimize memory allocations and sprintf()
invocations please, thxgoodbye! */
should make sure enough that people changing the code keep in mind that
the call is performance-sensitive.
> 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.
Wel, keep it readable, that's most important...
> PS: I thought Nokia hooked you up with a N900 or such?
Yeah, and I sold it on ebay a while ago... ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
