Abracadabra extension causes performance issues with other extensions (prettier formatting, etc.)

[dinofx]

I have prettier set as my formatter and format on save enabled. If I:

1. open a large JS file, for example a bundle created by webpack with 50,000 lines, then
2. open a file with 15 lines of code
3. Add a few extra newlines to the end of the small file and save

I see a popup and the save is delayed for a long time.

If I disable this extension, the problem goes away. I tried setting an ignore pattern to include the folder containing the large JS file, but I wasn't able to workaround the delay.

The problem has affected other extensions as well. For example, I tried several extensions that simply display the absolute character offset. When working in large files, these extensions would all display an initial offset but then would stop updating as the caret moved around. Also I couldn't invoke the "go to offset" command for the extensions.

[maxpatiiuk]

Seeing very bad performance when doing "Go to definition" in a large typescript definitions file (115k lines):

out.mp4

When trying to save, I get this:

Using VS Code's extension bisect, found that Abracadabra is the cause - when it is disabled, performance in the 115k line file is awesome

[nicoespeon]

Thanks for reporting. To be honest, I'm not surprised. I didn't have perfs in mind when I started implementing these refactorings.

It was working fine on files of reasonable size at first. The more refactorings we added to the catalog, the worse the perfs went, especially on large files. The exclusion feature was supposed to help, but it doesn't seem to.

We have had other obvious instances of this (see #416) and I believe something like #836 would be the solution. I haven't taken the time to dig into it, but I will think about it. In the meantime, https://marketplace.visualstudio.com/items?itemName=p42ai.refactor may be a better alternative so you have a catalog of refactorings, but with better perfs (I think).

[dinofx]

A simple short-term solution might be to disable the feature for files above a certain size. I think I've seen code-folding or some other feature take this approach with a 1-time popup indicating that it self-disabled due to file size.

[nicoespeon]

@dinofx that's a great idea!

I just shipped a release that contains a new setting abracadabra.maxFileLinesCount which should do that: don't evaluate refactorings based on the size of the file. It's configurable, but I put a 10,000 LOC default. If you can give it a try, let me know if that resolves your issue with the large bundles 🤞

I also made changes that reduced the bundle size quite a lot for the latest release. I think that should also help: #934

[j4k0xb]

The goal is to reduce the impact on performance when you have a large file (eg. a bundle) in your codebase.

I often open large bundles, but the problem is that they are minified and therefore 1 line long.
How about a size limit (e.g. in kb/mb) instead of LOC?

[nicoespeon]

@j4k0xb true. A size limit would certainly be smarter indeed 🤔

[nicoespeon]

The new option abracadabra.getMaxFileSizeKb should help with that. IMO, we now have plenty of options and sensible defaults that should address this.

However, feel free to re-open if you still experience bad performances because of Abracadabra.