Improve startup time #3673

Closed
benogle opened this Issue Sep 30, 2014 · 46 comments

Comments

Projects
None yet
@benogle
Contributor

benogle commented Sep 30, 2014

Status: This is an ongoing effort.

Via @kevinsawicki

The current plan is to investigate what is slow on startup, optimize it, and then investigate concatenating all the CoffeeScript requires to save eval time on startup.

Merged Changes

Times below are were taken with a Macbook Pro on OS X 10.8.5 with 2.6 Ghz Intel Core i7 processors and 16 GB of memory

  • atom/less-cache@dbddce5
    • Saves ~40ms when starting Atom with a fully warm Less cache
  • #3453
    • Cuts browser process launch time by ~33%
    • Saves ~60ms on startup
  • #3470
    • Cuts time taken to apply stylesheets by ~66%
    • Saves ~40ms on startup
  • atom/wrap-guide#16
    • Saves ~10ms on startup
  • #3519
    • Saves ~250ms on startup
  • atom/tree-view#219
    • Saves ~200ms on startup for large projects.
  • atom/status-bar#35
    • Save ~30ms on startup
  • atom/tabs#82
    • Saves ~15ms on startup
  • #3917
    • Reduces number of files read at startup
  • #3761
    • Caches requires across all installed packages and speeds up require resolution

@benogle benogle added the in-progress label Sep 30, 2014

@benogle benogle added the 1.0-roadmap label Sep 30, 2014

@benogle benogle referenced this issue Sep 30, 2014

Closed

Atom 1.0 #3684

18 of 25 tasks complete
@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Oct 1, 2014

You can also take a look at electron/electron#251, maybe you can get some speed there.

You can also take a look at electron/electron#251, maybe you can get some speed there.

@ilanbiala

This comment has been minimized.

Show comment
Hide comment
@ilanbiala

ilanbiala Oct 2, 2014

Looks really awesome so far. Are these changes available in the latest releases of Atom, or are they only going to be available in 1.0?

Looks really awesome so far. Are these changes available in the latest releases of Atom, or are they only going to be available in 1.0?

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Oct 2, 2014

Member

The listed changes have already been merged, and I'm pretty sure they're all in 0.133.0.

Member

50Wliu commented Oct 2, 2014

The listed changes have already been merged, and I'm pretty sure they're all in 0.133.0.

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Oct 2, 2014

Member

Yup, they are all in the latest release

Member

kevinsawicki commented Oct 2, 2014

Yup, they are all in the latest release

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Oct 6, 2014

Member

Moving this back to on-deck since nothing specific to this issue is being worked on this week.

Member

kevinsawicki commented Oct 6, 2014

Moving this back to on-deck since nothing specific to this issue is being worked on this week.

@tjfwalker

This comment has been minimized.

Show comment
Hide comment
@tjfwalker

tjfwalker Oct 24, 2014

Startup-time is my biggest and only serious gripe with Atom. All improvements are much appreciated.

Startup-time is my biggest and only serious gripe with Atom. All improvements are much appreciated.

@backspaces

This comment has been minimized.

Show comment
Hide comment
@backspaces

backspaces Oct 24, 2014

You may want to look at fast.js. Many parts of coffeescript use push where direct assignment is faster when the array size is known. In array comprehensions without an "if" conditional, the final array is known and should fast.js techniques.

You may want to look at fast.js. Many parts of coffeescript use push where direct assignment is faster when the array size is known. In array comprehensions without an "if" conditional, the final array is known and should fast.js techniques.

@kevinsawicki

This comment has been minimized.

Show comment
Hide comment
@kevinsawicki

kevinsawicki Oct 24, 2014

Member

@backspaces Thanks for the tip, looking into fast.js

Member

kevinsawicki commented Oct 24, 2014

@backspaces Thanks for the tip, looking into fast.js

@picibucor

This comment has been minimized.

Show comment
Hide comment
@picibucor

picibucor Nov 24, 2014

Check this out: #4293

Check this out: #4293

@tomByrer

This comment has been minimized.

Show comment
Hide comment
@tomByrer

tomByrer Nov 28, 2014

If you like fast.js style of overriding built-in functions, try Lo-Dash. Modern build is faster sometimes. The beta/preview has lazy evaluation which may also help.

If you like fast.js style of overriding built-in functions, try Lo-Dash. Modern build is faster sometimes. The beta/preview has lazy evaluation which may also help.

@bthusby

This comment has been minimized.

Show comment
Hide comment
@bthusby

bthusby Dec 30, 2014

Hope speed will come soon :)

bthusby commented Dec 30, 2014

Hope speed will come soon :)

@m1ga

This comment has been minimized.

Show comment
Hide comment
@m1ga

m1ga Jan 11, 2015

👍 me too! The main problem I have at the moment: I start atom (which takes a bit) and then select my old project to open (which takes a while because in linux it opens a second window). After the window is open the speed is fine. Just the "opening" time could be better

m1ga commented Jan 11, 2015

👍 me too! The main problem I have at the moment: I start atom (which takes a bit) and then select my old project to open (which takes a while because in linux it opens a second window). After the window is open the speed is fine. Just the "opening" time could be better

@hyiltiz

This comment has been minimized.

Show comment
Hide comment
@hyiltiz

hyiltiz Jan 12, 2015

I hate the fact that I have to wait seconds for my editor to open a file; all I do is editing.

hyiltiz commented Jan 12, 2015

I hate the fact that I have to wait seconds for my editor to open a file; all I do is editing.

@batjko

This comment has been minimized.

Show comment
Hide comment
@batjko

batjko Jan 22, 2015

Contributor

How is everyone's impression these days, both compared to a few months ago and to other similar editors?

Personally, I find massive improvements in startup time since, say, version 150 or even 160. It's not quite on the level of Notepad++ (yet), but it's certainly not enough time to get a coffee anymore. I'd say roughly on par with many equivalent full-featured editors.

Contributor

batjko commented Jan 22, 2015

How is everyone's impression these days, both compared to a few months ago and to other similar editors?

Personally, I find massive improvements in startup time since, say, version 150 or even 160. It's not quite on the level of Notepad++ (yet), but it's certainly not enough time to get a coffee anymore. I'd say roughly on par with many equivalent full-featured editors.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 22, 2015

Contributor

When I started using atom 9 months ago I was getting 6 to 8 second loads.
When the big fix was made it went down to 2 to 3 seconds. Unfortunately I
have added so many packages it has gone back to 6 or 7 seconds. I suspect
that I can remove half of the packages. That might get it back down.

On Thu, Jan 22, 2015 at 11:50 AM, batjko notifications@github.com wrote:

How is everyone's impression these days, both compared to a few months ago
and to other similar editors?

Personally, I find massive improvements in startup time since, say,
version 150 or even 160. It's not quite on the level of Notepad++ (yet),
but it's certainly not enough time to get a coffee anymore. I'd say roughly
on par with many equivalent full-featured editors.


Reply to this email directly or view it on GitHub
#3673 (comment).

Contributor

mark-hahn commented Jan 22, 2015

When I started using atom 9 months ago I was getting 6 to 8 second loads.
When the big fix was made it went down to 2 to 3 seconds. Unfortunately I
have added so many packages it has gone back to 6 or 7 seconds. I suspect
that I can remove half of the packages. That might get it back down.

On Thu, Jan 22, 2015 at 11:50 AM, batjko notifications@github.com wrote:

How is everyone's impression these days, both compared to a few months ago
and to other similar editors?

Personally, I find massive improvements in startup time since, say,
version 150 or even 160. It's not quite on the level of Notepad++ (yet),
but it's certainly not enough time to get a coffee anymore. I'd say roughly
on par with many equivalent full-featured editors.


Reply to this email directly or view it on GitHub
#3673 (comment).

@ilanbiala

This comment has been minimized.

Show comment
Hide comment
@ilanbiala

ilanbiala Jan 22, 2015

I've noticed that it still runs slower than Sublime/N++ or other native editors, and it cannot handle more startup packages like a native editor can..

I've noticed that it still runs slower than Sublime/N++ or other native editors, and it cannot handle more startup packages like a native editor can..

@benogle benogle added the on-deck label Feb 19, 2015

@Globegitter

This comment has been minimized.

Show comment
Hide comment
@Globegitter

Globegitter Feb 20, 2015

Yep same here - really like Atom Text editor, but the only thing so far noticeably worse compared to Sublime is performance. Especially startup time, having roughly the same amount of plugins. Hope there is still some room for improvements.

Yep same here - really like Atom Text editor, but the only thing so far noticeably worse compared to Sublime is performance. Especially startup time, having roughly the same amount of plugins. Hope there is still some room for improvements.

@charleswhchan

This comment has been minimized.

Show comment
Hide comment
@charleswhchan

charleswhchan Feb 20, 2015

On my PC:

  • Notepad++ starts up <1s
  • Atom v0.181.0 starts up ~3-5s (clean install)

Noticeably improvement! Keep up the good work.

On my PC:

  • Notepad++ starts up <1s
  • Atom v0.181.0 starts up ~3-5s (clean install)

Noticeably improvement! Keep up the good work.

@asantos3

This comment has been minimized.

Show comment
Hide comment
@asantos3

asantos3 Mar 27, 2015

Hopefully someone can enlighten me or tell me if they have or not the same problem.

I'm running Ubuntu 14.04. I start the PC and then start atom, it takes about ~12s to startup but then if I close it and start it again it takes about ~3s. I also have Windows in it and the startup is about ~40s and then the startup time is about the same. Is there a better way to debug this instead of just viewing timecop?

Is this normal or what? I don't see any running processes related to atom after I close it so I doubt it's do to being in memory.

Hopefully someone can enlighten me or tell me if they have or not the same problem.

I'm running Ubuntu 14.04. I start the PC and then start atom, it takes about ~12s to startup but then if I close it and start it again it takes about ~3s. I also have Windows in it and the startup is about ~40s and then the startup time is about the same. Is there a better way to debug this instead of just viewing timecop?

Is this normal or what? I don't see any running processes related to atom after I close it so I doubt it's do to being in memory.

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Mar 28, 2015

Member

I believe it's because Atom has to load everything from fresh the first time. Every startup after that, some of those things are cached and therefore it takes much less time to load.

Member

50Wliu commented Mar 28, 2015

I believe it's because Atom has to load everything from fresh the first time. Every startup after that, some of those things are cached and therefore it takes much less time to load.

@batjko

This comment has been minimized.

Show comment
Hide comment
@batjko

batjko Mar 28, 2015

Contributor

Yes, this has been observed on Windows ever since Window support came out. I wasn't aware it affects Linux as well, but there you go.

Having said that, since Windows got the squirrel updater, people don't normally have to re-install from scratch, so this issue should affect most Windows users only once.

Time for Linux to get an updater as well.

Contributor

batjko commented Mar 28, 2015

Yes, this has been observed on Windows ever since Window support came out. I wasn't aware it affects Linux as well, but there you go.

Having said that, since Windows got the squirrel updater, people don't normally have to re-install from scratch, so this issue should affect most Windows users only once.

Time for Linux to get an updater as well.

@m1ga

This comment has been minimized.

Show comment
Hide comment
@m1ga

m1ga Mar 28, 2015

@asantos3 have a look at iotop:
#5566
I have 4 apps running the first time

m1ga commented Mar 28, 2015

@asantos3 have a look at iotop:
#5566
I have 4 apps running the first time

@asantos3

This comment has been minimized.

Show comment
Hide comment
@asantos3

asantos3 Mar 29, 2015

@m1ga just tested it, doesn't happen with me. Have you tried other distros?

@m1ga just tested it, doesn't happen with me. Have you tried other distros?

@m1ga

This comment has been minimized.

Show comment
Hide comment
@m1ga

m1ga Mar 29, 2015

@asantos3 no sorry. It only happens at the first start in a KDE session. So if it was open before it won't show up again. But it might get fixed with asar. So I'll wait

m1ga commented Mar 29, 2015

@asantos3 no sorry. It only happens at the first start in a KDE session. So if it was open before it won't show up again. But it might get fixed with asar. So I'll wait

@asantos3

This comment has been minimized.

Show comment
Hide comment
@asantos3

asantos3 Mar 29, 2015

Just cleared up my buffer cache and the startup took about the same time as the first run. As @m1ga said, hopefully this is fixed with asar. Keep up the good work 👍

Just cleared up my buffer cache and the startup took about the same time as the first run. As @m1ga said, hopefully this is fixed with asar. Keep up the good work 👍

@jeffmcneill

This comment has been minimized.

Show comment
Hide comment
@jeffmcneill

jeffmcneill Apr 19, 2015

I use multiple Atom windows with multiple tabs in each window instance. I launch these from scripts. I'm on OSX 10.10 Macbook Air 2011 with 4gb RAM. It takes about 4 seconds to launch each window (after the first instance each window launches an Atom Helper process with about 100mb ram).

Is there any way I can get that 4 second launch time down to 1-2 seconds?

I use multiple Atom windows with multiple tabs in each window instance. I launch these from scripts. I'm on OSX 10.10 Macbook Air 2011 with 4gb RAM. It takes about 4 seconds to launch each window (after the first instance each window launches an Atom Helper process with about 100mb ram).

Is there any way I can get that 4 second launch time down to 1-2 seconds?

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Apr 19, 2015

Member

There will be some speed improvements arriving in 0.193.0. You can also try starting Atom with the --one argument if you don't have any packages that rely on deprecated APIs. For most people that speeds up loading time by 200-500ms.

Member

50Wliu commented Apr 19, 2015

There will be some speed improvements arriving in 0.193.0. You can also try starting Atom with the --one argument if you don't have any packages that rely on deprecated APIs. For most people that speeds up loading time by 200-500ms.

@jeffmcneill

This comment has been minimized.

Show comment
Hide comment
@jeffmcneill

jeffmcneill Apr 29, 2015

@50Wliu Thanks I do see some improvement with the -1 and on 0.194.0. Still some more speed would be nice, but there is progress here.

@50Wliu Thanks I do see some improvement with the -1 and on 0.194.0. Still some more speed would be nice, but there is progress here.

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Apr 29, 2015

Contributor

@jeffmcneill is atom --safe any faster? You may have packages slowing things down. Looking at timecop (cmd-shift-p, search for timecop) will show you which ones are the biggest offenders.

Contributor

benogle commented Apr 29, 2015

@jeffmcneill is atom --safe any faster? You may have packages slowing things down. Looking at timecop (cmd-shift-p, search for timecop) will show you which ones are the biggest offenders.

@yongkangchen

This comment has been minimized.

Show comment
Hide comment
@yongkangchen

yongkangchen Apr 29, 2015

Member

I suggest that atom should have package load level instead of load all package at start time.
For example:

  • tabs、status-bar、tree-view are the level 1, which load and active on start.
  • other packages are level 2, which should delay load and active when atom started.

see #4293

Member

yongkangchen commented Apr 29, 2015

I suggest that atom should have package load level instead of load all package at start time.
For example:

  • tabs、status-bar、tree-view are the level 1, which load and active on start.
  • other packages are level 2, which should delay load and active when atom started.

see #4293

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Apr 29, 2015

Contributor

instead of load all package at start time

What if a level 2 package modifies the appearance of a level 1? Then you
would see a "pop".

On Tue, Apr 28, 2015 at 11:03 PM, Yongkang Chen notifications@github.com
wrote:

I suggest that atom should have package load level instead of load all
package at start time.
For example:

  • tabs、status-bar、tree-view are the level 1, which load and active on
    start.
  • other packages are level 2, which should delay load and active when
    atom started.

see #4293 #4293


Reply to this email directly or view it on GitHub
#3673 (comment).

Contributor

mark-hahn commented Apr 29, 2015

instead of load all package at start time

What if a level 2 package modifies the appearance of a level 1? Then you
would see a "pop".

On Tue, Apr 28, 2015 at 11:03 PM, Yongkang Chen notifications@github.com
wrote:

I suggest that atom should have package load level instead of load all
package at start time.
For example:

  • tabs、status-bar、tree-view are the level 1, which load and active on
    start.
  • other packages are level 2, which should delay load and active when
    atom started.

see #4293 #4293


Reply to this email directly or view it on GitHub
#3673 (comment).

@jeffmcneill

This comment has been minimized.

Show comment
Hide comment
@jeffmcneill

jeffmcneill Apr 29, 2015

I've disabled several core packages, including markdown preview, and things have sped up. See attached for my Timecop on one of the instances (with 5 tabs, about 14,000 words that the wordcount needed to count.

screen shot 2015-04-29 at 1 10 01 pm

It's not instantaneous but definitely better. I use atom to write books with (previously used Multimarkdown and others). Each chapter is a markdown+latex file. With notes and other items, about 30 text files are in a directory (only about 7 might load into tabs).

@benogle --safe is faster, but I can't tell exactly because Timecop doesn't load. My process also adds a little overhead as I am double-clicking on .sh scripts to launch a Terminal that then executes change directory and invoking Atom.

Total load time is in the 3-4 second range (using a stopwatch). It does feel faster now. A 2 second load would be nice to have at some point. The tuning with turing off packages and using -1 and the latest version is definitely an improvement.

Latest Timecop:

screen shot 2015-04-29 at 1 24 18 pm

I've disabled several core packages, including markdown preview, and things have sped up. See attached for my Timecop on one of the instances (with 5 tabs, about 14,000 words that the wordcount needed to count.

screen shot 2015-04-29 at 1 10 01 pm

It's not instantaneous but definitely better. I use atom to write books with (previously used Multimarkdown and others). Each chapter is a markdown+latex file. With notes and other items, about 30 text files are in a directory (only about 7 might load into tabs).

@benogle --safe is faster, but I can't tell exactly because Timecop doesn't load. My process also adds a little overhead as I am double-clicking on .sh scripts to launch a Terminal that then executes change directory and invoking Atom.

Total load time is in the 3-4 second range (using a stopwatch). It does feel faster now. A 2 second load would be nice to have at some point. The tuning with turing off packages and using -1 and the latest version is definitely an improvement.

Latest Timecop:

screen shot 2015-04-29 at 1 24 18 pm

@yongkangchen

This comment has been minimized.

Show comment
Hide comment
@yongkangchen

yongkangchen Apr 29, 2015

Member

Just for a example. Package should can define the level in package.json, so
package which modifies the appearance should be defined level 1.

2015-04-29 14:13 GMT+08:00 mark-hahn notifications@github.com:

instead of load all package at start time

What if a level 2 package modifies the appearance of a level 1? Then you
would see a "pop".

On Tue, Apr 28, 2015 at 11:03 PM, Yongkang Chen notifications@github.com
wrote:

I suggest that atom should have package load level instead of load all
package at start time.
For example:

  • tabs、status-bar、tree-view are the level 1, which load and active on
    start.
  • other packages are level 2, which should delay load and active when
    atom started.

see #4293 #4293


Reply to this email directly or view it on GitHub
#3673 (comment).


Reply to this email directly or view it on GitHub
#3673 (comment).

Member

yongkangchen commented Apr 29, 2015

Just for a example. Package should can define the level in package.json, so
package which modifies the appearance should be defined level 1.

2015-04-29 14:13 GMT+08:00 mark-hahn notifications@github.com:

instead of load all package at start time

What if a level 2 package modifies the appearance of a level 1? Then you
would see a "pop".

On Tue, Apr 28, 2015 at 11:03 PM, Yongkang Chen notifications@github.com
wrote:

I suggest that atom should have package load level instead of load all
package at start time.
For example:

  • tabs、status-bar、tree-view are the level 1, which load and active on
    start.
  • other packages are level 2, which should delay load and active when
    atom started.

see #4293 #4293


Reply to this email directly or view it on GitHub
#3673 (comment).


Reply to this email directly or view it on GitHub
#3673 (comment).

@ypresto

This comment has been minimized.

Show comment
Hide comment
@ypresto

ypresto Jun 21, 2015

Contributor

I created PR for improvement here!
atom/deprecation-cop#54

Contributor

ypresto commented Jun 21, 2015

I created PR for improvement here!
atom/deprecation-cop#54

@Penagwin

This comment has been minimized.

Show comment
Hide comment
@Penagwin

Penagwin Jul 8, 2015

Do plugins load asynchronously? Can they even load asynchronously? Would that help load times at all?

Penagwin commented Jul 8, 2015

Do plugins load asynchronously? Can they even load asynchronously? Would that help load times at all?

@jpxd

This comment has been minimized.

Show comment
Hide comment
@jpxd

jpxd Aug 19, 2015

Async package loading would be really great!
On some packages I try to cheat at the activation time by adding a timeout and executing the activation code 5 seconds later to shorten the time until I see the editor window. I would love If one could specify when the package has to be loaded and activated in the package.json in cases where activationCommands are not an option.

E.g.
sync loading before editor is shown or
async loading in the background after the editor is ready and already shown to the user.

jpxd commented Aug 19, 2015

Async package loading would be really great!
On some packages I try to cheat at the activation time by adding a timeout and executing the activation code 5 seconds later to shorten the time until I see the editor window. I would love If one could specify when the package has to be loaded and activated in the package.json in cases where activationCommands are not an option.

E.g.
sync loading before editor is shown or
async loading in the background after the editor is ready and already shown to the user.

@lethevimlet

This comment has been minimized.

Show comment
Hide comment
@lethevimlet

lethevimlet Nov 10, 2015

As a quick fix atom editor should have a background service like chrome does, this a simple solution that should work even with lots of packages and improve the experience on non SSD owners. Service mode could have an enable/disable option for people who might be short on RAM, but now days a small service running in the background shouldn't be an issue for any hardware. This doesn't mean startup improvement efforts should be halted, nevertheless atom as a service should be a option no matter the startup time.

I think atom is awesome, and js (and friends) as the GUI is a perfect choice, with all the promised "hackability" and beauty only achievable by a cornucopia of options, but IMO most user, including me will be drawback by the current startup speed ~4s.

A text editor, no matter how many cool things it has, will fail as a text editor if startup time is >1s simply because the experience is not acceptable compared to other native apps, this fact won't pass unnoticed to most people, but once again its just my constructive opinion.

As a quick fix atom editor should have a background service like chrome does, this a simple solution that should work even with lots of packages and improve the experience on non SSD owners. Service mode could have an enable/disable option for people who might be short on RAM, but now days a small service running in the background shouldn't be an issue for any hardware. This doesn't mean startup improvement efforts should be halted, nevertheless atom as a service should be a option no matter the startup time.

I think atom is awesome, and js (and friends) as the GUI is a perfect choice, with all the promised "hackability" and beauty only achievable by a cornucopia of options, but IMO most user, including me will be drawback by the current startup speed ~4s.

A text editor, no matter how many cool things it has, will fail as a text editor if startup time is >1s simply because the experience is not acceptable compared to other native apps, this fact won't pass unnoticed to most people, but once again its just my constructive opinion.

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Nov 10, 2015

Contributor

IMO most user, including me will be drawback by the current startup speed ~4s.

Note that there are a few huge speedups coming up in the next couple versions of atom:

  • Huge speedup from a native compile cache #9318 (in master)
  • Unfold all 🐎 #9468 (in master)
  • Lazy snippet loading atom/snippets#182 (soon to be in master)

Startup speed is @as-cii's full time focus right now. He is finding and improving things weekly, so keep an eye out for new stuff!

Contributor

benogle commented Nov 10, 2015

IMO most user, including me will be drawback by the current startup speed ~4s.

Note that there are a few huge speedups coming up in the next couple versions of atom:

  • Huge speedup from a native compile cache #9318 (in master)
  • Unfold all 🐎 #9468 (in master)
  • Lazy snippet loading atom/snippets#182 (soon to be in master)

Startup speed is @as-cii's full time focus right now. He is finding and improving things weekly, so keep an eye out for new stuff!

@lethevimlet

This comment has been minimized.

Show comment
Hide comment
@lethevimlet

lethevimlet Nov 10, 2015

Great!, looking forward to it, nice work.

Great!, looking forward to it, nice work.

@tomByrer

This comment has been minimized.

Show comment
Hide comment
@tomByrer

tomByrer Jan 8, 2016

When measuring speed, might want to factor in Chrome's garbage collection services.

tomByrer commented Jan 8, 2016

When measuring speed, might want to factor in Chrome's garbage collection services.

@ilanbiala

This comment has been minimized.

Show comment
Hide comment
@ilanbiala

ilanbiala Mar 30, 2016

@benogle any update on this?

@benogle any update on this?

@passeride

This comment has been minimized.

Show comment
Hide comment
@passeride

passeride Dec 9, 2016

Suggestion: i have disabled some packages for faster startup, now if i could toggle them from the Shift+Ctrl P menu, that would be a great addition for me (But not as default tho), also would it be possible for a deamon to keep it running in background?

Suggestion: i have disabled some packages for faster startup, now if i could toggle them from the Shift+Ctrl P menu, that would be a great addition for me (But not as default tho), also would it be possible for a deamon to keep it running in background?

@Tzrlk

This comment has been minimized.

Show comment
Hide comment
@Tzrlk

Tzrlk Mar 8, 2017

Any thoughts on incorporating something like #4293 to get the editor displaying faster up-front? Or adding an option on the plugins to delay their startup?

Additionally, have you thought about using something like http://rollupjs.org/ for tree-shaking? Certainly running a tree-shake, minify and bundle as a runtime cache per combination of plugins should get subsequent load times up a bit?

Tzrlk commented Mar 8, 2017

Any thoughts on incorporating something like #4293 to get the editor displaying faster up-front? Or adding an option on the plugins to delay their startup?

Additionally, have you thought about using something like http://rollupjs.org/ for tree-shaking? Certainly running a tree-shake, minify and bundle as a runtime cache per combination of plugins should get subsequent load times up a bit?

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Mar 8, 2017

Member

We are actively working on this in #13949, #13940, #13916, and other PRs.

Member

50Wliu commented Mar 8, 2017

We are actively working on this in #13949, #13940, #13916, and other PRs.

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Mar 8, 2018

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

  1. Verify that you can still reproduce the issue in the latest version of Atom
  2. Comment that the issue is still reproducible and include:
    • What version of Atom you reproduced the issue on
    • What OS and version you reproduced the issue on
    • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

stale bot commented Mar 8, 2018

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

  1. Verify that you can still reproduce the issue in the latest version of Atom
  2. Comment that the issue is still reproducible and include:
    • What version of Atom you reproduced the issue on
    • What OS and version you reproduced the issue on
    • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

@stale stale bot added the stale label Mar 8, 2018

@stale stale bot closed this Mar 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment