Asynchronous for 2.0?


#1

I understand that Atom isn’t and won’t be written asynchronously for the 1.0 milestone, but will the internals be changed to do so (post 1.0)?


#2

There are a number of critical components that are async, such as opening a file.

Async in node is for parallelism. One web page being served shouldn’t block another. In Atom, most of the code is in the path of UI interaction. When you click on a key you want the response immediately. Something running async would harm that experience.

There are things like-autocompletion that should be async. My personal opinion is that those types of things should be done in a separate process.


#3

What exactly would you like to happen asynchronously?


#4

Opening the command palette seems a little laggy when dealing with large projects.

And to mark_hahn, when I was browsing the source, iI noticed that readFileSync was being used rather than readFile. But that was a little while ago so maybe it’s different now.


#5

Why would async make this faster?

Yes, that makes opening the command palette faster.


#6

I’m saying it would make the palette itself display faster, then you would be able to see the commands populate in it when ever they are loaded.

And how does loading the file synchronously make a faster ui presentation?


#7

I feel like this is going to be an unproductive discussion. The initial question is the same as asking, “Is Microsoft Word going to be multithreaded?” There is no good way to answer that question. Parts of Microsoft Word are multithreaded. Other parts aren’t. Hopefully the parts that are multithreaded are the ones that make sense.

Like everything, Asynchronous vs. Synchronous code is a trade off, there is no one right answer for all possible situations. Will Atom be taking a look at performance vs. responsiveness on an ongoing basis? Definitely. Will the Atom team make changes as appropriate? Absolutely.


#8

I didn’t say it made the presentation faster. I meant the whole process is faster.

If you want the dialog to be usable before it is finished, then yes, that would require async operations. But there are other problems with that scheme, like having the contents change out from under you while trying to use it. That would be a UX decision. In general you can’t show a sorted list until you get all items. The newly found items would have to be added to the bottom, possibly hiding the best fits.

In any case, I’m just trying to discourage a common idea that async is inherently faster. Node makes people think this way. But a web server is quite different from Atom.


#9

Well Put @mark_hahn .

@ZehCnaS34 Async is only Fast when that asycn operation Doesn’t consume all resource. There is no use for async for those case that takes full CPU/Resources.

On async web servers , if one async CPU heavy task consumes all resources it blocks other requests too , unless it is moved to worker process.


#10

@mark_hahn, and @v3ss0n thanks for clearing everything up.