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

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].

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

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

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]

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?

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]

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]

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.

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.