Hi Michael,

Thank you for the test running tips. The reason I noticed that the Tramp
tests were an outlier in terms of time to execute was not that I was
running the entire set of Tramp tests. My pet project is getting as much
as possible of Emacs and its tests to run with Edebug/Testcover code
coverage turned on in order to generate code coverage reports. The
volume of data structures created for code coverage cause garbage
collection to be expensive. Everything runs slower with code coverage
on, but expensive garbage collection makes even the "make check" set of
Tramp tests run extremely slowly.

Looking at the code coverage reports gave me some insight into why Tramp
does so much garbage collection. tramp-file-name-structure gets called
over 2 million times during the full run of Tramp tests, and creates
strings and builds a list each time, but only constructs one of three
possible results depending on the value of tramp-syntax. The result
lists are not modified by the code they are returned to.

In the attached patch I have modified tramp-file-name-structure and its
subroutines so that the three results are calculated once and then
looked up when needed. With this patch the full set of Tramp tests takes
1/3 as long to complete as before.

It's not my use case, but it seems possible that this patch would be a
noticable performance improvement to someone who keeps a long running
Emacs process with lots of data loaded (hence costly garbage collection)
and also uses Tramp heavily over fast network connections.

Besides the patch I'm attaching two coverage reports which you may find
interesting. The code coverage data were created by running the full
set of Tramp tests, one without the patch and one with the patch. The
reports were generated with genhtml from a lcov info file written by a
modified version of Testcover which collects execution counts. The
number between the line number and the code on each line is the maximum
of the execution counts of the forms in that line of code.

Best regards,
Gemini