From wagner riffel to ~sircmpwn/sr.ht-discuss
FWIW, andOTP was removed from f-droid and the links in sourcehut referring to it are now dead, one I could find is in man/meta[1]. 1 - https://man.sr.ht/meta.sr.ht/#two-factor-authentication
From wagner riffel to ~rjarry/aerc-devel
On Sun Mar 6, 2022 at 10:28 PM CET, inwit wrote: > I'm confused with the fact that > it is spending almost one third of the time in textproto.(*Part).Close. The x-axis of this graph is not time, it's just sorted by name, the y-axis is the stack depth, so which function that took majority of time was syscall.Read, not textproto.(*Part).Close, you can read this graph as Run calls handleAction, handleActions calls handleMessage ... NextPart calls Close which calls io.Copy ... until syscall.Read, which is the one that uses most of time, it looks like a similar problem as getDirectoryInfo, it's doing way too much i/o. > I don't even know if this is a bug in aerc or not, that's why I'm hesitant to > report it as such. I've reported at go-maildir, however [1].
From wagner riffel to ~rjarry/aerc-devel
On Sun Mar 6, 2022 at 7:35 PM CET, inwit wrote: > > Indeed no. They happened just the same before your patch. I'm very sorry for > not being clear before about this. I guess I was hoping that maybe this could > ring some bell, since you know that part of the code. I wish I knew how to > debug this. I guess there's some spurious processing going on on those silent > 20s, but I really don't have a clue about how would I look into it. There's any open issue for this? If not I think you should create one and move this topic to there, what I did to debug was use go runtime/pprof, I suggest you do the same, apply the patch attached, which simply profiles for 5 seconds, saves the pprof data to aerc.prof and exits aerc, then you can investigate with "go tool pprof" command, if you have no familiarity with its command line idiom, I suggest you
From wagner riffel to ~rjarry/aerc-devel
On Sun Mar 6, 2022 at 11:58 AM CET, inwit wrote: > However, I'm attaching two logs produced after opening my "sent" folder (~20K > messages), one with the Maildir interface and other with notmuch. As you can > see, there is a lag of ~20s. In both cases, the lag occurs after the call to > types.FetchDirectoryContents, which stalls silently and then produce errors > related to the mime structure of some of my mails. > > Is this an expected behaviour? I'm not surprised that some of my mails have a > wrong structure, but other softwares do not complain of this and gets to open > my folder much faster (especially notmuch). > Those errors seems unrelated with this changes, 20s lag is very surprising, can you confirm that they only happen after applying this
From wagner riffel to ~rjarry/aerc-devel
Fix a data race due dirInfo pointer being read in the main goroutine
by NewMessageStore and written in the anonymous goroutine launched in
Worker.getDirectoryInfo.
To address the issue raised in https://todo.sr.ht/~rjarry/aerc/16, we
use readdir(3) once, parse and cache its results, this replaces
go-maildir library Dir.Flags based stat(3) and filepath.Glob
causing the issue when N (emails) is large.
Signed-off-by: wagner riffel <w@104d.net>
---
All previous versions of this patch were broken because it's missing a
seek to reset readdir position to the beginning, I found this nicer
[message trimmed]
From wagner riffel to ~rjarry/aerc-devel
On Sat Mar 5, 2022 at 2:52 PM CET, Robin Jarry wrote: > I wonder if your optimization could be integrated directly into > go-maildir. It would be better than to have a "workaround" in aerc. > I'm not sure, due the current Dir type of go-maildir (just string) it will be needed to use at least one open(3)/close(3) per call of Dir.Flag, I dropped this patch there, that reduced the loop run time from 4.5s to 3.4s, still not as good as leaving the file descriptor opened as I did for aerc. > I am not any expert neither. Did you ensure that message counts seemed > the same before and after your patch?
From wagner riffel to ~rjarry/aerc-devel
Fix a data race due dirInfo pointer being read in the main goroutine
by NewMessageStore and written in the annonymous goroutine launched in
Worker.getDirectoryInfo.
To address the issue https://todo.sr.ht/~rjarry/aerc/16 replace
go-maildir library Dir.Flags with our own based on readdir(3)
Signed-off-by: wagner riffel <w@104d.net>
---
On Mon Feb 28, 2022 at 12:29 AM CET, Robin Jarry wrote:
> This is almost a revert of a commit I made recently to fix a performance
> problem when opening maildir folders containing large number of
> messages:
>
[message trimmed]
From wagner riffel to ~rjarry/aerc-devel
Fix a data race due dirInfo pointer being read in the main goroutine by NewMessageStore and written in the annonymous goroutine launched in Worker.getDirectoryInfo. Signed-off-by: wagner riffel <w@104d.net> --- worker/maildir/worker.go | 53 +++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 28 deletions(-) diff --git a/worker/maildir/worker.go b/worker/maildir/worker.go index 6ff66b2..03ffd6b 100644 --- a/worker/maildir/worker.go +++ b/worker/maildir/worker.go @@ -145,36 +145,33 @@ func (w *Worker) getDirectoryInfo(name string) *models.DirectoryInfo { [message trimmed]
From wagner riffel to ~sircmpwn/aerc
On Wed Apr 28, 2021 at 3:01 AM -03, Reto Brunner wrote: > @Wagner: Happy with me including your name? > Sure thing, no problem. The patch LGTM.
From wagner riffel to ~sircmpwn/aerc
On Mon Apr 26, 2021 at 4:34 PM -03, Reto wrote: > I can't reproduce the error anymore with the event loop stalling at > least in > the notmuch worker. > > Can you try what happens if you simply remove the double emit of the > event? > It's clearly the wrong thing to do anyhow. > Hi Reto, I think I mentioned this on the patch email, I did test and actually I'm using for some weeks this exact approach, I just deleted the second emit, I see no apparent problems so far.