GNU bug report logs - #33210
Cuirass: Use a SQLite in single-thread mode

Previous Next

Package: guix-patches;

Reported by: Clément Lassieur <clement <at> lassieur.org>

Date: Tue, 30 Oct 2018 20:36:03 UTC

Severity: normal

Done: Clément Lassieur <clement <at> lassieur.org>

Bug is archived. No further changes may be made.

Full log


Message #52 received at 33210-done <at> debbugs.gnu.org (full text, mbox):

From: Clément Lassieur <clement <at> lassieur.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 33210-done <at> debbugs.gnu.org
Subject: Re: [bug#33210] Cuirass: Use a SQLite in single-thread mode
Date: Thu, 13 Dec 2018 14:57:47 +0100
Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Clément,
>
> Clément Lassieur <clement <at> lassieur.org> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hello,
>>>
>>> Clément Lassieur <clement <at> lassieur.org> skribis:
>>>
>>>> These patches are supposed to slightly improve Cuirass' performances,
>>>> because it doesn't use the multi-threading features.
>>>
>>> Did you notice a measurable difference?
>>
>> I haven't done any measurement yet, but according to the SQLite
>> documentation:
>>
>>     Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and
>>     thread-safety logic in SQLite to be omitted. This is the single
>>     compile-time option that makes the most difference in optimizing the
>>     performance of SQLite.
>>
>> So even if the optimization is small, it's the option that has the
>> biggest impact on performance.
>>
>>> We could do it, but IMO that should be a last resort because I’d expect
>>> it to be a micro-optimization.
>>
>> Lots of micro-optimizations lead to an overall faster application ;-).
>> And this one doesn't make the code more complicated.  To me it's just a
>> bonus.
>
> I agree it doesn’t complicate the code; still, that’s a couple of
> additional package variants to deal with, for hardly measurable benefits
> I suspect.
>
> I think we should focus on higher-level optimizations at this
> development stage of Cuirass.  For instance I have been meaning to patch
> it so that it doesn’t have to process all the build logs, since it
> doesn’t do anything with those logs and processing them involves tons of
> syscalls and string processing and introduces latency in fiber
> scheduling.  This is a simple change that could have a more visible
> impact I believe.  Hopefully I’ll get there real soon…

Understood!

Sorry to reply that late.  Closing.

Clément




This bug report was last modified 6 years and 217 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.