Metals: Switch to incremental sync instead of full sync

Created on 13 Dec 2017  路  6Comments  路  Source: scalameta/metals

/**
 * Defines how the host (editor) should sync document changes to the language server.
 */
export namespace TextDocumentSyncKind {
    /**
     * Documents should not be synced at all.
     */
    export const None = 0;

    /**
     * Documents are synced by always sending the full content
     * of the document.
     */
    export const Full = 1;

    /**
     * Documents are synced by sending the full content on open.
     * After that only incremental updates to the document are
     * send.
     */
    export const Incremental = 2;
}

Currently we do the full-sync, which sends the whole file contents on every keystroke

Most helpful comment

Closing as wontfix for now. We have no evidence so far to suggest that full text synchronization is a performance bottle-neck in Metals.

All 6 comments

What's the downside of full text sync? Did you observe/suspect any perfect degradation because of this?

Haven't observed any problems, just find it unsatisfying that the full source file is moved on every keystroke. I haven't worked with it in larger files however (>7k loc)

It makes sense. Let's only hope we don't suddenly start goin out of sync :)

I'm talking out of the blue (no idea what we're talking about really), but wouldn't it be possible to do "checkpoints" every once in a while, redoing full sync, and use incremental sync in-between checkpoints?

@ivanopagano during the initialize handshake, the server communicates if it supports incremental/full text synchronization and it's not possible to change the mode after that.

Closing as wontfix for now. We have no evidence so far to suggest that full text synchronization is a performance bottle-neck in Metals.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

olafurpg picture olafurpg  路  13Comments

jastice picture jastice  路  32Comments

olafurpg picture olafurpg  路  19Comments

dgalichet picture dgalichet  路  14Comments

virtualdvid picture virtualdvid  路  17Comments