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

calcurse slow #459

Open
mvhulten opened this issue Apr 29, 2023 · 2 comments
Open

calcurse slow #459

mvhulten opened this issue Apr 29, 2023 · 2 comments

Comments

@mvhulten
Copy link

Version 4.8.0, on OpenBSD current.

Navigation through days/weeks/months is very slow (on aremote host). It takes several seconds for all text to be shown properly when switching from one to another day, e.g. by pressing t.

I have been using calcurse for many years. Over the last couple of years it became slower and slower. The apts file has grown to 564527 bytes (and includes repeated apts including exceptions).

When I remove the apts file, calcurse is very fast. Removing keys and conf does not help.

On a local machine (also OpenBSD current), navigation is much more responsive. There is a noticable delay when switching between days, but it is only a fraction of a second.
Over the local network (ssh to that same system), navigation in calcurse is less responsive but not as bad as on the remote host.

So the slowness appears to come about from the grown apts, and gets significantly worse when further away (network-wise).

Is this a bug? Is it expected?
Would it be wise to simply clean out apts (e.g. everything older than a year)?

@mvhulten
Copy link
Author

I have resolved this slowness issue by removing pre-2023 apts, except for recurring that still run.
This could be easily done by editting apts.
I version-control-tagged the commit herefore, s.t. I can easily find/retrieve old items.

My original agenda went back to March 2012. For me this is an indication that (intensive) use for over 10 yr can be problematic. Feel free to leave it open for further investigation/tests. Feel free to close it; for me the issue is resolved/under control.

@lfos
Copy link
Owner

lfos commented May 30, 2023

Thanks for the bug report, Marco. This sounds like a scalability issue we should investigate.

The difference in local vs. remote is very surprising -- are you sure the root cause is distance/network and not an unrelated difference between the two machines/systems (e.g., the remote machine having slower hardware than the local machine)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants