atom / timecop

Show where Atom spends time

Atom and all repositories under Atom will be archived on December 15, 2022. Learn more in our official announcement

Timecop package

Displays information about where time is spent while Atom loads.

• Startup time
• Compile cache
• Package loading time
• Package activation time
• Theme loading time
• Theme activation time

Inspired by Timecop the movie. ⌚ 🚨

timecop's Issues

Can't scroll the Timecop view

I opened the timecop view with the Timecop: View command.

The Package Loading column is clearly too long for my window. However, scrolling is not possible neither with the touchpad nor the arrow keys.

Mac OS X 10.9.2
Atom 0.60.0

Does not report "human time" to startup

See issue atom/atom#2654

The actual time it takes from typing atom [mydir] to seeing an editor can be double of what timecop says the start time is. The startup below actually took 3 seconds (timed on my phone). More examples can be found in the linked issue above.

Link to packages

I just saw that the top* package is one I've never used.
It should be easy to remove offending packages.
A link could work, although there could be a more prominent (and direct) button to uninstall it as well
I was about to say maybe just have uninstall buttons for packages in the red, but that would be a bad idea.

*for loading. For package activation, status-bar is coming in at a whopping 2308ms

Add a button for dumping the metrics to a buffer

Rather than posting screenshots for comparison like in atom/atom#3405, it would be great if we could click a button and dump all the stats into a text file to paste into a GitHub Issue or Discuss post.

Makes it searchable too!

Add time taken to read/parse storage file

To help diagnose storage file size issues when reading the window state from the ~/.atom/storage folder.

atom/atom#2654 (comment)

Order of items in the 'Startup Time' pane

Very minor indeed, but should the order of the first two items in the Startup Time section: namely 'Window load time' and 'Shell load time' be switched?

Currently:
Window load time
Shell load time
...

Re-ordered:
Shell load time
Window load time
...

This would seem to be the more logical order taking into account the other three items that follow.

workspace/project load times are undefined

# lsb-release -a
LSB Version:	core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
Distributor ID:	openSUSE Tumbleweed
Description:	openSUSE Tumbleweed
Release:	20170213
Codename:	n/a

# uname -a
Linux machine 4.10.9-1-default #1 SMP PREEMPT Sat Apr 8 15:30:03 UTC 2017 (195f937) x86_64 x86_64 x86_64 GNU/Linux

# atom -v
Atom    : 1.17.0-beta3
Electron: 1.3.14
Chrome  : 52.0.2743.82
Node    : 6.5.0

Running atom --safe and checking timecop shows:

Can only reproduce when Atom starts with no projects.

Cannot copy timecop results with cmd-c

Add metrics for packages shutdown

It may comes handy to find which package(s) is causing the unresponsive window dialog to appear.

Add list of packages that were loaded and/or activated immediately on startup

With all the new features for lazy loading of packages, we should add a list of packages that activate immediately on startup so that package authors can see or be notified that they should take advantage of the new features.

<unknown> is deprecated.

Directly from Deprecation Cop:

You have the core package "timecop" installed as a community package. See https://github.com/atom/dalek for how this causes problems and instructions on how to correct the situation.

<unknown> (<embedded>:13400:20)
Generator.next (null:null:null)
step (<embedded>:13387:279)
<unknown> (null:null:null)
process._tickCallback (internal/process/next_tick.js:109:7)

I don't know what it means, I hope it'll be helpful.

Compile Cache basically useless

Normally, if you switch themes, the stylesheets need to be regenerated, reload and they're not re-generated. Okay, cool.

Uninstall/disable/update some packages and every reload takes the same amount of rebuilds and the start time increases.

Without a detailed view, or tooltip, or something, this is now impossible to debug...

Provide a way of reporting slow packages

Deprecation cop provides the nice feature of quickly letting you file a bug for a package that uses a deprecated function. It'd be great if time cop let me do a similar thing with packages that are very slow to load or activate.

I imagine sometimes packages are just randomly slow because the whole system is slow, so this might need to be mediated by some other service to compute whether the slowness is a repeated thing.