Micro Taking over 100% CPU Usage

[plyght]

Description of the problem or steps to reproduce

Run micro

Specifications

Micro v. 2.0.14
MacOS Sequoia 15.1 Beta (24B5035e)
M3 MacBook Pro 16GB RAM 1TB SSD

Commit hash: 04c5770
OS: MacOS Sequoia 15.1 Beta (24B5035e)
Terminal: Warp (v0.2024.09.24.08.02.stable_01)

[JoeKar]

Run micro

Hm, sounds a bit unspecific. Did you open a specific file or is it really just opening a plain micro session?

[plyght]

Run micro

Hm, sounds a bit unspecific. Did you open a specific file or is it really just opening a plain micro session?

@JoeKar Do anything w/ Micro. This includes opening a plain 'new' session, document, etc. Apologies for the unspecific reproduction steps.

[JoeKar]

Ok, I could imagine such a behavior with a specific file bringing the current highlighter logic (already planned to be exchanged) into trouble. But this should definitely NOT happen in case you open a single plain session in micro with no other bufferw being present.

Since we've no MacOS setup available it's hard for us to reproduce this scenario and thus we need your help to narrow down the problem resp. performance bottleneck.
Please perform the following command in your shell:

micro -profile

This just opens a single plain session, which is then profiled. After maybe 5-10s you can close this session and upload the created micro.prof file, which hopefully reveals the issue.

[plyght]

Ok, I could imagine such a behavior with a specific file bringing the current highlighter logic (already planned to be exchanged) into trouble. But this should definitely NOT happen in case you open a single plain session in micro with no other bufferw being present.

Since we've no MacOS setup available it's hard for us to reproduce this scenario and thus we need your help to narrow down the problem resp. performance bottleneck. Please perform the following command in your shell:

micro -profile

This just opens a single plain session, which is then profiled. After maybe 5-10s you can close this session and upload the created micro.prof file, which hopefully reveals the issue.

@JoeKar here is the file. micro.prof.zip

[JoeKar]

Can you please paste your settings.json here? Looks like autosave is used, which consumes more or less the same as draw.
Hm, but looks like the wrong path...even after 13s of duration it only sampled 60ms of data. 🤔

[plyght]

Can you please paste your settings.json here? Looks like autosave is used, which consumes more or less the same as draw. Hm, but looks like the wrong path...even after 13s of duration it only sampled 60ms of data. 🤔

@JoeKar Here is the file. settings.json

[Andriamanitra]

Ok, I could imagine such a behavior with a specific file bringing the current highlighter logic (already planned to be exchanged) into trouble. But this should definitely NOT happen in case you open a single plain session in micro with no other bufferw being present.
Since we've no MacOS setup available it's hard for us to reproduce this scenario and thus we need your help to narrow down the problem resp. performance bottleneck. Please perform the following command in your shell:

micro -profile

This just opens a single plain session, which is then profiled. After maybe 5-10s you can close this session and upload the created micro.prof file, which hopefully reveals the issue.

@JoeKar here is the file. micro.prof.zip

I don't see anything out of the ordinary in the profile. Are you sure the unusually high CPU usage was happening during the profiling? It's possible that the CPU usage comes from something that the profiler can't capture, but if that's the case it's going to be hard/impossible to debug without access to a system where the problem can be reproduced.

[plyght]

Ok, I could imagine such a behavior with a specific file bringing the current highlighter logic (already planned to be exchanged) into trouble. But this should definitely NOT happen in case you open a single plain session in micro with no other bufferw being present.
Since we've no MacOS setup available it's hard for us to reproduce this scenario and thus we need your help to narrow down the problem resp. performance bottleneck. Please perform the following command in your shell:

micro -profile

This just opens a single plain session, which is then profiled. After maybe 5-10s you can close this session and upload the created micro.prof file, which hopefully reveals the issue.

@JoeKar here is the file. micro.prof.zip

I don't see anything out of the ordinary in the profile. Are you sure the unusually high CPU usage was happening during the profiling? It's possible that the CPU usage comes from something that the profiler can't capture, but if that's the case it's going to be hard/impossible to debug without access to a system where the problem can be reproduced.

@Andriamanitra @JoeKar Apologies; I just figured out that it's one file that is the issue. (I found this out just now, as when I "quit" [^ + Q], the process still runs and so if I attempt to open another file, it'll still say ≥100% CPU usage)

This is odd though because this file is not that big of a file, and the character count is not high at all. (7,963 characters/8kb) here is the file, and here is a screen recording of me opening the file, copying all its contents, and then trying to paste it into another one.

I also have tried opening bigger HTML files including a 20kb file.

[Andriamanitra]

@plyght Ok with that file I can reproduce the issue on Linux too. The problem is caused by the long lines in the file (lines 1 and 15 are over 1000 characters long). Micro's syntax highlighting system often struggles to handle long lines gracefully.

Maybe we should make syntax highlighting skip lines that are longer than a certain threshold?

[plyght]

@plyght Ok with that file I can reproduce the issue on Linux too. The problem is caused by the long lines in the file (lines 1 and 15 are over 1000 characters long). Micro's syntax highlighting system often struggles to handle long lines gracefully.

Maybe we should make syntax highlighting skip lines that are longer than a certain threshold?

@Andriamanitra great! that seems like a good idea! 👍

[dmaluka]

Ah, I know what's the issue here. It is the same issue as #2839 and #3115.

It is fixed by @JoeKar's PR #3127. We still haven't merged it (we're yet to properly review it), but we plan to merge it before 2.0.15.

I've checked that with #3127 applied there is no issue: the file immediately gets highlighted and there is no high CPU usage. @plyght so if you feel like it, you can compile micro with #3127 applied, it should fix the problem for you.

The problem is caused by the long lines in the file (lines 1 and 15 are over 1000 characters long). Micro's syntax highlighting system often struggles to handle long lines gracefully.

In this case the problem is different (and much worse), it is not just about long lines, it is about what I described in #3127 (comment).

[JoeKar]

Ok, I could imagine such a behavior with a specific file bringing the current highlighter logic (already planned to be exchanged) into trouble.

So my first suspicion was confirmed. :)

@dmaluka: Thank you for testing it already with #3127. Otherwise I would have done exactly the same. 👍

[plyght]

Ah, I know what's the issue here. It is the same issue as #2839 and #3115.

It is fixed by @JoeKar's PR #3127. We still haven't merged it (we're yet to properly review it), but we plan to merge it before 2.0.15.

I've checked that with #3127 applied there is no issue: the file immediately gets highlighted and there is no high CPU usage. @plyght so if you feel like it, you can compile micro with #3127 applied, it should fix the problem for you.

The problem is caused by the long lines in the file (lines 1 and 15 are over 1000 characters long). Micro's syntax highlighting system often struggles to handle long lines gracefully.

In this case the problem is different (and much worse), it is not just about long lines, it is about what I described in #3127 (comment).

@dmaluka any updates on @JoeKar's PR and it's merge status?

[JoeKar]

@plyght I'm currently the one who is "blocking" this PR, since I've to respond to @dmaluka's review comments and most probably have to rework the PR accordingly. Sorry, I didn't find the time so far, since I was focusing on a other major PR when I had the time to do so.
#3127 is, as of now, being scheduled for v2.0.15 to fix #2839 as well.