search

fregante / GhostText

👻 Use your text editor to write in your browser. Everything you type in the editor will be instantly updated in the browser (and vice versa).
https://GhostText.fregante.com
MIT License
3.29k stars 117 forks source link

Limit the update rate when editing large files #40

Closed Cacodaimon closed 3 years ago

Cacodaimon commented 9 years ago

This is a optional feature, which should limit the number of updates send to the client per second to an user defined maximum per second.

This should improve the performance when working with large file.

The a maximum wait time before sending an update could be defined in milliseconds the ST user preferences.

When the user sets this value 100ms for example, the maximum number of updates per second would be limited to 10.

fregante commented 9 years ago

Can SublimeText know when the browser has finished receiving an update? Rather than using an arbitrary throttling duration, SublimeText could wait for the browser's response before sending a new update. Could that work?

Cacodaimon commented 9 years ago

Can SublimeText know when the browser has finished receiving an update? Rather than using an arbitrary throttling duration, SublimeText could wait for the browser's response before sending a new update. Could that work?

We could update the protocol sending an "update processed message" back to the server, but this solutions drawback would be heavy increased complexity.

Let's take the JS code editor with the Firefox add on as currently most complex solution of message passing, the pages JS scope has to inform the content script scope that the text change has been processed this message has to be passed to the main script which has to pass the message to the background script which finally sends the "update processed message" to the server.

The server code needs some more logic, too. Take a look at the current Atom prototype: https://github.com/Cacodaimon/GhostText-for-Atom/blob/master/lib/ghost-text.coffee less than 80 lines of code are enough for a minimalistic solution or this prototype of an gedit3 plug in: https://gist.github.com/Cacodaimon/eebeb67043b3acef3282 140 lines + the ST plugin's WebSocket and HTTP code are enough for this prototype to work.

I like your Idea because it is more deterministic, but I'm afraid that increasing the complexity could slow down the development.

We have no statistics about the used, but I believe the most texts edited with GT are smaller ones like this comment rather large CSS files which caused this issue: Connection errors #31 #29 . Which could means that this issue would increase the complexity for less than 20% of the use cases.