On 16.02.18 11:29, Urs Riggenbach via enigmail-users wrote: > Hello, > > I've been using Enigmail and it's nicely integrated with Tunderbird. > > When sending large attachments, I have often 10 seconds or more wait times. > > I think this because of some architectural flaw as when I dump the > encrypted email to a file and run gpg to decrypt it it takes less than a > second. > > Can someone explain why this is the case and where I should start to > make a patch?
There are several reasons why processing is slow. * The most important reason lies deep in the architecture of the Mozilla platform. We access child processes (stdin/stdout/stderr) from JavaScript via an API-call to stdlib/some windows DLL. From what I heard from the Mozilla people, that API generates a _lot_ of overhead as it needs to translate the input data of a JavaScript string into raw data for the C library and vice-versa for the output. To make things more complicated, this needs to be done in different native threads, which is not really available in JavaScript. The only way to achieve this is to use "Workers". And the API to use workers is message-based, which makes things again slower. The library has been re-written by Mozilla about a year ago, but it's still not much faster than it was before. * The second reason lies in the way we get the data from the MIME parser. Enigmail gets the data line by line, which means that there are many calls for a large message. As accessing the child process is pretty slow, Enigmail gathers the complete message in memory and then hands it over to the child process. This is still a _lot_ faster than doing many calls to C-library. The disadvantage is that we gather the data as a constantly growing string. This is not particularly quick and may consume considerable amounts of RAM. This could also be a reason why send large emails is slow. If you want to try to fix this, then start with mimeEncrypt.jsm and subprocess.jsm: <https://sourceforge.net/p/enigmail/source/ci/master/tree/package/mimeEncrypt.jsm> <https://sourceforge.net/p/enigmail/source/ci/master/tree/ipc/modules/subprocess.jsm> In theory, it would probably be faster to write the input data to a file, call gpg to encrypt it to a new file, and read the resulting file back into a JavaScript string. However, I _really_ don't like this approach. -Patrick
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enigmail-users mailing list [email protected] To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
