Working with a slow internet connection can be very frustrating. And with our previous file-saving procedure, working on large files in SourceLair was sometimes a pain. Given a large enough file and a slow enough connection, the required time to save a file could easily get out of hand and the workflow disruption was too big to ignore.

And our goal here at SourceLair is to remove any possible strain from your workflow. So after identifying the problem we searched for the best possible way to solve it.

Saving files faster

Problem

Everytime you save a tab, the whole file is sent over the network to our servers and overwrites the previous contents of the file.

Obviously, by increasing the size of the file you are working on, the request data gets bigger and bigger and the bottleneck of the network becomes evident. There are cases where saving a huge file could take up to 30 secs and of course this is unacceptable.

Searching for a solution

Transfering 100KB everytime you make a small change of 100 bytes costs time and network traffic. Since, most of the time, the changes are just a fraction of the actual file, why don't we just send the changes? So our goal was to find out that fraction of the file that changed, send it as a patch and apply it on the actual file on the server.

To avoid reinventing the wheel, for both calculating the patches in the front end and applying them in the back end, we utilized Neil Freiser's google-diff-match-patch. This dramatically reduced the data size sent for a save request. Reducing the data lead to decreasing the response time.

Result

To showcase the speed improvement, we run a simple benchmark. The following graph shows the average response time for saving a file in regard to its size. Three different cases were run:

• Saving a file like we used to
• Saving a 1000 line change with patching
• Saving a 100 line change with patching

(for the patching cases, the time for the calculation of the patches is included in the response time)

It is obvious that with our previous implementation there is a linear relationship between the file size and the response time. With the new implementation, response time is bound only to the size of the changes and is no more dependent on the file's size. An average save now is reduced to just 150-200ms no matter the size.

So now we've seen how save became a lot faster! Time to find out why it's smarter as well.

Saving files smarter

With the introduction of live file system you can rest assured that any changes in your files are reflected in your filesystem and your editor. There are some cases though in which the file you are working on gets outdated. Lets say for example that you go home after work and you open your home computer and you still have SourceLair on. Due to the lack of internet connection, any changes made in the meantime did not update your IDE. This could lead to you editing and saving an old version of your file, overwriting any precious progress you made at work.

To avoid this, from now on, everytime you save your file, we check that the version you are editing and are trying to save is indeed the latest one. In case it isn't, you'll be notified and will be able to either force save your version, or load the latest version from the server.

With the introduction of these two new features, saving files in SourceLair is both faster and smarter.

Go to www.sourcelair.com and start coding frictionlessly!