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

Extreme RAM consumption (it use more then 15 GB) #1648

Open
guthipp opened this issue Jun 1, 2024 · 11 comments
Open

Extreme RAM consumption (it use more then 15 GB) #1648

guthipp opened this issue Jun 1, 2024 · 11 comments
Assignees
Labels
potential bug (works for me) issues cannot be reproduced under developer's environment

Comments

@guthipp
Copy link

guthipp commented Jun 1, 2024

Description

Hello Team CotEditor,

my MacBook Pro M1 has 16 GB RAM and CotEditor needs more then 15 GB RAM. But why? I can't believe, that this is intentional. It makes my MacBook noticeably slower.

It's not just since yesterday. I really hope, you can fix this bug.

PS: I have to say, I have round about 150 Tabs .txts open. But not books... the most .txts have just a few lines and no one is longer than 10000 characters pure text maximal.

aktiv kontext

Thanks in Advance.

To Reproduce

Its not immediately.. its when the CotEditor is open a few weeks... it getting more and more. And: I have to say, I have round about 30 Tabs .txts open. But not books... the most .txts have just a few lines and no one is longer than 10000 characters pure text maximal.

Expected behavior

RAM use not higher than 1 GB ... I mean... its just text!!

CotEditor version

4.8.6

macOS version

14.5 (23F79)

Additional context

No response

@guthipp guthipp added the potential bug issues not yet tested label Jun 1, 2024
@1024jp
Copy link
Member

1024jp commented Jun 2, 2024

Thank you for making a new ticket.

ref. #1592

@1024jp 1024jp added better to fix unwanted behaviors better to fix and removed potential bug issues not yet tested labels Jun 2, 2024
@1024jp 1024jp self-assigned this Jun 2, 2024
@1024jp
Copy link
Member

1024jp commented Jun 2, 2024

I am re-inspecting the current source code in terms of memory leaks.

So far, I found that there is a memory leak on the macOS side the instance around the input method UI remains when the app closes a window.

Screenshot 2024-06-02 at 20 35 36

That is, the more windows are closed in the same session, the more memory is used. This can be one reason, and if so, third-party developers cannot do anything. I will report this to Apple as an issue.

Second, there is a tendency in recent macOS in general that the system uses RAM greedily and lets it free when required. So if you feel no practical issue caused by using a lot of RAM, it would be within the acceptable range.
(But even though, I personally feel 16 GB is quite a large number)

macOS uses a relatively large amount of memory when creating windows (tabs are also a kind of window). In my environment, just opening 30 empty documents requires immediately 1 GB. So your request below is difficult even if there are no other given conditions.

RAM use not higher than 1 GB ... I mean... its just text!!

Other than that, I could not find any particular cause for memory leaks at this time even using Xcode's memory leak extractor.
Of course, there can still be leaks hidden somewhere that cannot be easily discovered.
I will inspect further.


Taking the above into consideration, please let me ask a few questions on how to use the system to put the situation in perspective:

  1. You mentioned you use mostly .txt files. Is the syntax for those documents Plain Text or None without any customization?
  2. During your one month of use, did you open and close a lot of documents? Ore you only worked mostly with those 30 documents? If you remember, please let me know the rough number of documents you would open in the same session.
  3. Does the RAM usage significantly reduce if you close some windows?
  4. Could you share the screenshot of the General settings pane and the Edit settings pane?

@1024jp 1024jp added the awaiting reply issues waiting for a reply from issue reporter label Jun 2, 2024
@1024jp
Copy link
Member

1024jp commented Jun 2, 2024

Additional question:

its when the CotEditor is open a few weeks

But CotEditor 4.8.4 was released on 24th May. Just one week before.
What is the correct number?

Does CotEditor 4.8.4 use 15 GB within a week, or these numbers (a few weeks and 15GB) is with CotEditor 4.8.3 or earlier?
(This may seem like a loaded question, but it’s important to separate the issues.)

@1024jp
Copy link
Member

1024jp commented Jun 5, 2024

So far, I found that there is a memory leak on the macOS side the instance around the input method UI remains when the app closes a window.
...(ommition)... I will report this to Apple as an issue.

Filed: FB13818129

@guthipp
Copy link
Author

guthipp commented Jun 8, 2024

Does CotEditor 4.8.4 use 15 GB within a week, or these numbers (a few weeks and 15GB) is with CotEditor 4.8.3 or earlier?

Its bc I copyed the text. I use the newest Version (Version 4.8.5 (653) updated at 2. June)... so it seems to be happening even faster. It is currently using 15,3 GB.

1. You mentioned you use mostly .txt files. Is the syntax for those documents Plain Text or None without any customization?

I use CotEditor as an replace to the famous Windows Notepad++ just for notes (in the corner right top says "Plain Text") in every Tab. Btw. I see in the iCloude Drive it seems that I have openend roughly 150 .txt files (I am not sure if they are all open but I guess)

2. During your one month of use, did you open and close a lot of documents? Ore you only worked mostly with those 30 documents? If you remember, please let me know the rough number of documents you would open in the same session.

I mean I use it like a local note software ... so the old notes I sometimes open when I am looking for something.. its hard to say how often I often the most of the old tabs ... but I would say sometimes.

3. Does the RAM usage significantly reduce if you close some windows?

When I close a tab, then it reduce 10-20 MB of RAM.

4. Could you share the screenshot of the General settings pane and the Edit settings pane?

grafik
grafik

@1024jp
Copy link
Member

1024jp commented Jun 9, 2024

Thank you for the reply!
This information will help my further investigation.
Let me have another time.

@1024jp 1024jp added potential bug (works for me) issues cannot be reproduced under developer's environment and removed awaiting reply issues waiting for a reply from issue reporter better to fix unwanted behaviors better to fix labels Jun 9, 2024
@1024jp
Copy link
Member

1024jp commented Jun 9, 2024

If somebody meets a similar situation, let me know. So far, I asked this to users on Twitter, but no one respond yet, though someone kind users even reposted it.

@guthipp
Copy link
Author

guthipp commented Jun 10, 2024

I have some interessting news:

  • when I start the app then in a few seconds the RAM increase to 20 GB but then it settles at 15 GB (I dont know why I tought its not instant sorry... I thougt I already tested it)
  • for every new tab I open the RAM increase roughly 100MB ... whether I write something in or not
  • I counted the tabs: I have parallel opend roughly 150 tabs ... when you multiple it with 100 then 15 GB

@dimitrik-fr
Copy link

Probably makes sense to check since which exactly version these high RAM allocations started to happen in CotEditor.

Personally I continue to use CotEditor 4.5.9 (for compatibility with old Macs) and with 2 windows opened and having 7 tabs each (source code files of various length / size) -- RAM usage is around 340MB. However, this RAM usage can quickly grow as soon as I'm starting to edit, but will go back on CotEdit restart (with the same files re-opened again).

@guthipp
Copy link
Author

guthipp commented Jun 20, 2024

Newest Version 4.8.6. The Problem is still there:
Bildschirmfoto 2024-06-19 um 09 38 16

@1024jp
Copy link
Member

1024jp commented Jun 26, 2024

Thanks for the detailed information.

CotEditor is currently being refactored for the upcoming macOS 15 Sequoia.
This update will be released this fall.
I have not found the direct factor of this leak yet, but I'll try to fix this issue in this update through refactoring.
Also, if I find anything suspicious, I will not wait for macOS 15 but incorporate it into the regular patch updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
potential bug (works for me) issues cannot be reproduced under developer's environment
Development

No branches or pull requests

3 participants