On Mon, 18.02.13 08:00, Holger Freyther (hol...@freyther.de) wrote: > Cristian RodrÃguez <crrodriguez <at> opensuse.org> writes: > > Good Morning Cristian, > > > Why should systemd stop using standard IO functions to please some > > obscure, out of the ordinary need? > > Could you please clarify obscure? So any embedded device that prints > a couple of log messages on start of an application is obscure in your > opinion? It is obvious from the perf output I posted that journald's
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... > performance is determined by the malloc operations. If the maintainers > think that the main purpose of journald is to allocate memory then I am > happy to continue to use the busybox syslogd. 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... > > If libc behaves in a way you dont like or want, you will have to send > > your complains to libc developers.. > > Well, there are various things a libc implementation needs to do that > should not matter to systemd (e.g. thread safety, io cancellation, > re-entrancy, locking, ...). From the backtraces I posted only a fraction > of the allocations are coming from libc. To clarify this: I can totally see value reducing the malloc()s in an inner loop call such as dispatch_message_real(). 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! (BTW, it might delight you to know that the client side of all this -- which is similar in style generally --, in journal-send.c actually avoids malloc()s almost completely -- there's only one left, since I couldn't come up with any nice way to avoid it. I carefully made sure of that -- but not really because for performance reasons but simply to avoid that we'd have to deal with OOM, and so that the OOM message itself would still be printable...) Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
