elm_code: 100% CPU/Memory on large files

[obsidian-studiosinc]

elm_code: 100% CPU/Memory on large files

[wltjr]

This maybe an elm code bug not sure.

[wltjr]

Opened task upstream T5497

[ApostolosB]

fgdgda.txt

the test file

[wltjr]

Not resolved with EFL 1.19.1 it does not crash, but never opens, seems to hang or something. Need to debug further.

[ApostolosB]

Just to update this. It stoped crashing on files. On huge ones it just hangs there being slow. At least on my slow system. Efl from git.

[wltjr]

Were you able to close it when it was slowly opening large files? For me I end up with a OOM and crash after a bit. It eats up CPU as well as RAM. I mentioned on the task T5497. Seems like some progress, but not 100% there yet.

[ApostolosB]

killall -9 ecrire did it. It hadn't been able to render anything on the screen though. And yes noticed the same. 100% CPU and eating ram.

[NuLogicSystems]

The CPU spike was fixed in EFL, but it does take a long time to load large files.
Maybe some sort of caching should be used here.

[wltjr]

Very likely, but all that is due to elm_code. Ecrire just passes the document to load to elm_code. Catching, performance, etc is all specific to elm_code. I may look into contributing and furthering elm_code, but not sure I fully understand it yet. If its even fully developed. I think elm_code is still considered experimental. I guess we can close this bug. Though I may wait till its fixed in a release version. I assume the fix is in git and not say 1.20.4 release.

Thanks for keeping me informed!

[wltjr]

Despite all related tasks being closed upstream. The issue still remains. I get 100% CPU when trying to open the document. EFL 1.20.5. Not sure about git, assuming that is the same.

[wltjr]

Adding upstream so they are aware of issues
@Enlightenment @ajwillia-ms @zmike

[andydotxyz]

The fact that it crashed was fixed. The high CPU usage appears to be a new issue. I have been working with ApBBB to resolve this new issue.

[andydotxyz]

I tried replicating that locally and I find:
It takes 15 seconds to open the file
The UI is a little sluggish when moving around
It takes 5 sec to close the file.

This is clearly not acceptable but I wanted to check that we are on the same page before I look into a fix.

[wltjr]

leafpad opens immediately, netbeans issues warning about size and maybe slow, but opens fine no delay. It may have something to do with processing, as in syntax. Given the issue reported in phab task 6209. Maybe totally unrelated, but maybe what ever is causing that lag could be causing lag on file load/close. Though that could be focus/select related. Much smaller file. This one never opens for me. Just freeze ecrire, maxes out a core, and memory starts increasing till OOM.

[NuLogicSystems]

I just tried opening fgdgda.txt in ecrire and ecrire never shows up (double click file), or just sits there frozen with the file-selector window open. All I can see it doing is slowly eat ram until I end up killing it's process in exterminator.

[wltjr]

Here is edi doing it as well, edi Desktop/fgdga.txt. No edi window, just what you see in htop

[ApostolosB]

Tried edi on my git system (a really slow one). Same behavior as with ecrire on it. 100%cpu, nothing on the screen and memory going up. At least the result is not as explosive as on my stable system.
Also tested l3afpad with the file and opened it without an issue.

[NuLogicSystems]

Same here, issue still present using efl-git.

[Peter2121]

Seriously improved in the last version of EFL (1.24.3).

[ApostolosB]

Seriously improved in the last version of EFL (1.24.3).

nahhh. still takes ages to open a 3.6MB file.

[wltjr]

It actually opened a couple times for me, but there were issues each time. It also crashed as I tried to navigate the document via scrollbars. It does seem to be a little better, or different, but remains an issue.