emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#33210: closed (Cuirass: Use a SQLite in single-thr


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#33210: closed (Cuirass: Use a SQLite in single-thread mode)
Date: Thu, 13 Dec 2018 13:58:03 +0000

Your message dated Thu, 13 Dec 2018 14:57:47 +0100
with message-id <address@hidden>
and subject line Re: [bug#33210] Cuirass: Use a SQLite in single-thread mode
has caused the debbugs.gnu.org bug report #33210,
regarding Cuirass: Use a SQLite in single-thread mode
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
33210: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33210
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Cuirass: Use a SQLite in single-thread mode Date: Tue, 30 Oct 2018 21:35:06 +0100 User-agent: mu4e 1.0; emacs 26.1
Hi,

These patches are supposed to slightly improve Cuirass' performances,
because it doesn't use the multi-threading features.

Clément



--- End Message ---
--- Begin Message --- Subject: Re: [bug#33210] Cuirass: Use a SQLite in single-thread mode Date: Thu, 13 Dec 2018 14:57:47 +0100 User-agent: mu4e 1.0; emacs 26.1
Ludovic Courtès <address@hidden> writes:

> Hi Clément,
>
> Clément Lassieur <address@hidden> skribis:
>
>> Ludovic Courtès <address@hidden> writes:
>>
>>> Hello,
>>>
>>> Clément Lassieur <address@hidden> 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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]