Re: invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior

[Havoc Pennington <hp redhat com>]

On Thu, 2005-09-15 at 20:11 -0400, Colin Walters wrote:
> On Tue, 2005-09-13 at 15:02 +0100, Ross Burton wrote:
> 
> > I'd expect in a UI application they won't make much difference, but I do
> > know that for the DBus port of EDS turning off asserts in DBus made a
> > 20% improvement in the speed benchmarks...
> 
> What is the benchmark exactly?  I can imagine that a 20% improvement in
> latency of address book retrieval might be interesting to investigate,
> if it (for example) made contact autocompletion in Evolution noticeably
> faster to the end user.  But my opinion is that removing or reducing the
> asserts in D-BUS to improve an artificial benchmark unrelated to end
> user tasks like "how many contacts can my script retrieve per second"
> isn't interesting.  We could spend all day optimizing desktop IPC, but
> our real speed problems are elsewhere (see Lorenzo Colitti's work).

dbus is intended to have --disable-asserts but --enable-checks in a
production release. I _think_ that's what the defaults are.

dbus only uses checks in public entry points, in fact I verify that with
this lame hack:
#define _dbus_return_if_fail(condition) do {
\   _dbus_assert ((*(const char*)_DBUS_FUNCTION_NAME) != '_');    

since private functions in dbus start with "_"

Note that since that's an assert it goes away in the production
build ;-)

I think some of the asserts are pretty expensive since I've always
assumed they'd be turned off. There are some not-entirely-free checks
also like validating name strings, but I think they are "worth it" and
should not be turned off. dbus is more about paranoia than speed.

Havoc