search

zyedidia / micro

A modern and intuitive terminal-based text editor
https://micro-editor.github.io
MIT License
24.94k stars 1.17k forks source link

Micro Taking over 100% CPU Usage #3487

Open plyght opened 3 days ago

plyght commented 3 days ago

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: 04c57704 OS: MacOS Sequoia 15.1 Beta (24B5035e) Terminal: Warp (v0.2024.09.24.08.02.stable_01)

SCR-20240930-lmfz SCR-20240930-lmng
JoeKar commented 3 days ago

Run micro

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

plyght commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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. :thinking:

plyght commented 3 days ago

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 commented 2 days ago

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 commented 2 days ago

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 commented 2 days ago

@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 commented 2 days ago

@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 commented 2 days ago

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 https://github.com/zyedidia/micro/pull/3127#issuecomment-1958589761.

JoeKar commented 2 days ago

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. :+1: