Git Product home page Git Product logo

Comments (3)

dbaeumer avatar dbaeumer commented on May 26, 2024

The pull diagnostics method as an unchanged property to signal that issue for a document have not changed. Incremental updating does not exist right now.

from language-server-protocol.

davidhalter avatar davidhalter commented on May 26, 2024

@keyboardDrummer Can you give us a more detailed overview what you think is a "large file" and awhat a lot of diagnostics would be?

Because in my experience the reason why things get slower is not the fact that a 100-1000 diagnostics are sent from the server to the client, but the fact that the server is busy parsing and doing type inference (which is probably 100 times more time intensive than sending the data).

from language-server-protocol.

keyboardDrummer avatar keyboardDrummer commented on May 26, 2024

Consumers of our VSCode extension (for Dafny) have files that are thousands of lines, and information diagnostics are likely to occur on every line. An information diagnostic per line may seem like a lot, but our language has a relatively high level of implicitness/inference (unrelated to types), so it can help to tell the user what the compiler has inferred from their code.

Sending a 1000 diagnostics for a single file might be OK, but we have the additional situation that we may send many publishDocument notifications for a single document change.

The reason for this is that our back-end has one fast phase (parsing/name resolution/type inference) that takes about a 100ms, but then does a complicated analysis (called verification) on separate program elements, of which a large file may have hundreds, that each can take between 100 and 1000 ms. Automatically running verification is in some ways very similar to automatically running unit tests. We publish diagnostics after the fast phase, but also each time verification of any element completes, so we may send a 100 publishDocument notifications.

What I'm worried about is sending 1000 (#lines * diagnostics/line) * 100 (amount of publishDocument calls) of elements per document change. I'll admit we are not evidently running into this at the moment, but it seems like our current design won't scale towards ever growing customers codebases.

I will say though we've extended LSP with a notification API to notify the client about the current progress of verification, so for each verifiable element to say whether it's: not being run/queued/running/completed. We could send additional diagnostics through this API, and use publishDocument only for the fast phase parsing/name resolution/type inference) diagnostics.

from language-server-protocol.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.