Re: invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior
- From: Ross Burton <ross burtonini com>
- To: Colin Walters <walters verbum org>
- Cc: Christian Neumair <chris gnome-de org>, Christopher James Lahey <clahey ximian com>, desktop-devel-list gnome org
- Subject: Re: invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior
- Date: Fri, 16 Sep 2005 08:46:39 +0100
On Thu, 2005-09-15 at 20:11 -0400, Colin Walters wrote:
> 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).
The bookmark was the artificial "how long does it take to do 1000 book
views, where a view asynchronously sends 160 contacts". I was profiling
and optimising this operation (as it's very frequent) and discovered
that with DBus asserts on, 20% of the time was spent performing checks.
I removed them simply to make optimisation easier.
Not that this is a bad thing mind, developer builds should have asserts
on for sanity checking. So yes, it was an artificial benchmark, and not
one which normal users would really notice for exactly the reasons I
stated: in a UI application the odd assert here and there is going to be
drowned out by human lag.
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]