Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid loading Org on init #120

Closed
meedstrom opened this issue Aug 26, 2021 · 7 comments
Closed

Avoid loading Org on init #120

meedstrom opened this issue Aug 26, 2021 · 7 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@meedstrom
Copy link

I don't know if you consider this relevant or if I should make an issue with Doom Emacs instead. Perhaps our use-package declarations should defer magit-todos until first time they call up a magit buffer anyway.

But if it's possible within this codebase to not load Org immediately, maybe it's a good feature? Takes work off the shoulders of Doom and other community configs.

@alphapapa
Copy link
Owner

Maybe. Lots of things in Emacs use Org, and loading it once means not having to call require every time we format an Org item . But if it's causing a problem (and I don't know if it is--no one's mentioned it until now), that call could be moved into the appropriate function.

@meedstrom
Copy link
Author

meedstrom commented May 4, 2022

Few people may bring up the issue here because they don't know it's magit-todos, like how I at first had difficulty figuring out why Emacs starts slow in the first place, and it took some time to figure out that something is loading Org, and then some time to figure out whodunit.

Anyway, does require take much compute cycles? The docstring gives me the impression that if the package is already loaded, it's nearly a no-op -- it just checks for a match in the list features, something like (member 'org features), but it's a C function so probably even faster.

@alphapapa
Copy link
Owner

So you mean that magit-todos's loading Org was causing your Emacs startup time to be too long? How much of a difference was it making?

@meedstrom
Copy link
Author

meedstrom commented Jun 6, 2022

With Org: 1.8s by stopwatch (Doom dashboard reports 1.5s, emacs-init-time reports 1.3s)

Without Org: 1.2s by stopwatch (Doom dashboard reports 0.9s, emacs-init-time reports 0.75s)

I guess it doesn't fit all definitions of "slow", but it's noticeable to me. Sorry, I can't offer advice on whether or not you should move the require invocation, other than to say I'd move it if it was my package (and I'm assuming there isn't a meaningful runtime performance hit). Guess it's up to your tastes. You can close the issue.

@jsigman
Copy link

jsigman commented Aug 6, 2022

Second that the requirement to load org early is stopping me from using this (otherwise) excellent package. The reason why has to do with the emacs-jupyter package, not startup time

@alphapapa alphapapa self-assigned this Aug 15, 2022
@alphapapa alphapapa added the enhancement New feature or request label Aug 15, 2022
@alphapapa alphapapa added this to the 1.6 milestone Aug 15, 2022
@alphapapa
Copy link
Owner

Ok, if it's presenting a problem, I don't mind making that change. Most cases won't involve an Org file anyway, and in the few that do, the change shouldn't be a performance problem, I think.

@alphapapa
Copy link
Owner

That should do it. Please let me know if the problem is solved for you.

alphapapa added a commit that referenced this issue Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants