mutmut browse is very slow and uses tons of memory

[enkore]

With a project this size (i.e. small)

Navigating to one of the larger modules takes a good while with 100% CPU. Memory climbs to around 10 GB RSS. Loading the code diff for a mutant takes a similar amount of time. This all seems really slow to me considering the program doesn't really have to do much.

I think this is because this event handler fires-and-forgets a get_diff_for_mutant thread, and this always seems to reparse the whole mutated module from scratch. In the example above that's ~20 MiB of code parsed per event (the source file is ~80K). This seems logical, the number of mutants doesn't scale linearly.

Parsing the mutant with ast:

33.87user 1.06system 0:35.24elapsed 99%CPU (0avgtext+0avgdata 2020668maxresident)k
40inputs+0outputs (0major+583561minor)pagefaults 0swaps

... and with libcst:

78.86user 4.93system 1:24.50elapsed 99%CPU (0avgtext+0avgdata 9609288maxresident)k
1968inputs+0outputs (1major+2687553minor)pagefaults 0swaps

I think the parsing here is largely unnecessary? When generating the mutants mutmut could store the source spans for each mutant and then reading the mutants would be very cheap. The original and mutated function source can then be parsed to rename the function before generating the diff (or just str.replacing the mutant name).

[Otto-AA]

the source file is ~80K

I'm scared 😮 That's the mutated file LoC?

This seems logical, the number of mutants doesn't scale linearly.

Ah true, a really long function will create a lot of mutants and each mutant makes a copy of the really long function. So probably n^2 depending on the function size. If you only have short functions, it should scale linearly with the file size.

And yes, in general I feel that mutmut browse could be much faster than it is currently.

Storing the line numbers of the generated mutations makes sense to me and would make it much faster. I think for that we'd need to visit all nodes of the generated code once more with a PositionProvider (or preferably MutatedMethodsCollector?) in mutmut.mutation.file_mutation.combine_mutations_to_source (and instead of returning only the names, return some dataclass with name + source span). This approach would make the mutant generation slower, so we'd need to check if that's worth it, or if there's another approach.

[enkore]

I'm scared 😮 That's the mutated file LoC?

Ah - no, 80K bytes and 20M bytes, respectively 😅 - relatively normal. But it is a parser with some quite large and branchy functions which end up having a lot of mutants.

Generation takes also quite a while (peaking at 2.2G RSS)

⠇ Generating mutants
done in 71891ms (8 files mutated, 0 ignored, 0 unmodified)

(Another topic though)

Storing the line numbers of the generated mutations makes sense to me and would make it much faster. I think for that we'd need to visit all nodes of the generated code once more with a PositionProvider (or preferably MutatedMethodsCollector?) in mutmut.mutation.file_mutation.combine_mutations_to_source (and instead of returning only the names, return some dataclass with name + source span). This approach would make the mutant generation slower, so we'd need to check if that's worth it, or if there's another approach.

I haven't looked at that side at all so far, but one general question: is the format of the "mutants" directory expected to be stable and persistent, or something that can be changed or extended?