Improving the performance regarding PSI

[Ezrnest]

The editor appears to be very laggy for relatively large tex files and I have been profiling the performance of the plugin to figure out why.

It seems that the current performance of the plugin can be greatly improved by refactoring the PSI related codes.

Optimizing PSI operations

On one hand, I found that some current codes operating on PSI can be improved, even with some minor changes.
Take the following fragment in LatexSectionFoldingBuilder.buildFoldRegions for example,
which took about 10% of the CPU time in my run profiling.

val commands = root.childrenOfType<LatexCommands>().filter { it.name in sectionCommands }
    // If it has no parameters, it is probably not an actual section but in a command definition
    .filter { it.parameterList.isNotEmpty() }
    // Similarly, if the section command is in a parameter it is probably in the preamble, and we should not fold
    .filter { it.firstParentOfType<LatexParameter>() == null }
    .sortedBy { it.textOffset }
val comments = root.childrenOfType<LatexMagicComment>().filter { it.key() == DefaultMagicKeys.FAKE }
// If the user has a custom folding region interleaving with sections, e.g. spanning multiple sections but ending inside a section, we give the user priority over the default section folding (so that the user does not need to put fake sections everywhere)
val customRegions = root.childrenOfType<LatexMagicComment>().filter { it.isStartRegion() || it.isEndRegion() }
val sectionElements: List<PsiElement> = (commands + comments).sortedBy { it.textOffset }

I think it has the following problems:

• The operation root.childrenOfType<LatexCommands> traverse the whole PSI tree and is very time-consuming, but it is called three times. The latter two calls return the same list and can be merged.
• List.filter operations can be merged, avoiding intermediate list creation.
  As a result, LatexSectionFoldingBuilder.buildFoldRegions

I believe it would improve a lot if we can optimize/rewrite the related codes.

Improving PSI structure

I have inspected the current construction of PSI tree and I found that plain words are represented by separate PSI elements.
I think that this can lead to extensive but unnecessary PSI elements.

Take the following as an example:

1 2 3 4 5 6 7 8

We will get one PSI element for each digit:

However, as they are merely plain texts, I think we should assign only one element as a whole, which is true if we inspect the PSI for Java string literal.

I think merging these PSI elements would greatly reduce the size of PSI tree and improve the performance.

[PHPirates]

The question is, for what size of 'large file' should we optimize? For me, 500 lines is a really large file and I rarely edit files larger than that. But recently, someone commented that it was slow editing a 4000 lines file.

As to the example, some obvious improvement is of course possible, but these kind of things have to be done on a case-by-case basis.

Interesting suggestion, it would result in less tokens, but where do you think this would be a performance improvement? Not for childrenOfType, because LatexNormalText.children is empty since NORMAL_TEXT_WORD is not a full psi element, but just a token. Not quite sure if combining would lead to problems in e.g. line wrapping, folding, or formatting, but we could try it out if it would be a performance improvement, simply removing the space in NORMAL_TEXT_WORD regex in LatexLexer.flex should do it.

Actually, the biggest performance problem we have is reading indexes, in particular stub indexes. To read all indexed commands takes like 30 seconds or so if texlive-full is indexed, and for other project-specific indexes it can also take a second or so easily, I suspect because they have to be read from disk. To work around it I have created a whole lot of caches littered everywhere, but these are difficult to keep fresh, and creates the problem of when to fill them (in the background). I have no idea what would be a proper solution for this.

[Ezrnest]

Indeed, LatexNormalText.children is empty but the frequently used helper function PsiElement.childrenOfType in Psi.kt would traverse through all the children including those NORMAL_TEXT_WORD.

I think perhaps another way is to reduce the use of PsiElement.childrenOfType as it traverse the whole tree.

[Ezrnest]

I usually have files with around 1000 lines full of math commands, and I sometimes feel it slow to edit files, especially when I use my laptop. For example, I have to wait for half a second when I press the enter.

[Ezrnest]

I can try to run some other profiles and investigate whether it is possible to improve the performance in reading indexes.

[PHPirates]

Hm half a second is too much, we should improve that. Maybe I should try to write a test for performance, it always deteriorates over time until it's quite bad.

[Ezrnest]

I am currently working on an improvement over LatexSectionFoldingBuilder and also LatexBreadcrumbsInfo.

It seems that LatexBreadcrumbsInfo will scan the whole file (viaLatexSectionFoldingBuilder().buildFoldRegions(element.containingFile, document, quick = true), where quick=true does nothing in LatexSectionFoldingBuilder) to determine a node's (structural) parent, which is called once for every LatexCommands, so the total time cost would be significant.

    override fun getParent(element: PsiElement): PsiElement? {
        val document = element.containingFile.document() ?: return super.getParent(element)
        // Add sections
        val parent = LatexSectionFoldingBuilder().buildFoldRegions(element.containingFile, document, quick = true)
            // Only top-level elements in the section should have the section as parents, other elements should keep their direct parent (e.g. an environment)
            .filter { it.range.contains(element.textRange ?: return@filter false) }
            .filter { !it.range.contains(element.parent?.textRange ?: return@filter false) }
            // Avoid creating a loop
            .filter { it.element.psi != element }
            .filter { it.element.psi?.parents()?.contains(element) != true }
            .minByOrNull { it.range.endOffset - it.range.startOffset }
            ?.element?.psi
        return parent ?: super.getParent(element)
    }

I will also try to improve the performance of the folding builders as they would traverse the whole document for multiple times.

[Ezrnest]

Here is a lengthy tex document for test, which is full of texts and math commands. (rename the suffix as Github does not allow uploading .tex document).

LengthyDoc.txt

[PHPirates]

Appreciate that, thanks. It is surprisingly hard to find really long latex documents online

[Ezrnest]

After #4087, I think that the main load of on the UI thread is the parser, which can hardly be improved unless we try to improve the lexer and PSI structure.

Regarding the plain texts, as far as I tested, we can indeed benefit a lot from merging words, especially when the document is mainly made of plain texts. Consider PlainTexts.txt.

Simply removing \s in the lexer would indeed greatly improve the performance. However, it would break a lot of tests. It seems that migrating the other functionalities would require much effort.