lem icon indicating copy to clipboard operation
lem copied to clipboard

[Performance][Windows] High resource use even when idle.

Open tmheath opened this issue 1 year ago • 3 comments

I noticed while messing around earlier that the new binary release (2.1) of Lem running on Windows 10 only idled around 3% as compared to 0% from the old version. My hunch is that some feature that tracks the mouse constantly on a single thread was added because when I move the mouse, even with Lem minimized, the processing of Lem increases to a maximum of a bit over 6%. The reason that I think this is a hundred divided by the number of threads in this laptop is the maximum resource usage. I don't know if Lem itself is single threaded but this might still be a single newly added feature because the last binary release idled at 0% irrespective of other workings, while the new release idles variable against what the mouse is doing.

I will not investigate this potential performance bug as I don't have the time but I figured it'd be good to document it at least. Not certain this is in fact a problem.

tmheath avatar Dec 07 '23 22:12 tmheath

Thanks for commenting the issue, I don't have any windows machine to test, so if someone with windows read this issue, feel free to test it :+1:

Sasanidas avatar Dec 08 '23 20:12 Sasanidas

Do you notice a performance hit or even a lag when you run M-x commands (or do anything really)? I did and found a workaround: https://github.com/lem-project/lem/issues/1092

vindarel avatar Dec 12 '23 11:12 vindarel

That is a separate problem. Whatever is causing this is affecting the Windows 2.1 binary release and seems to be associated with the mouse cursor moving over a period of time to a maximum use of one thread even if Lem is minimized. I read over that real quick and I've not noticed that, a number of the commands are broken but I'm not sure if that would be just me missing software.

tmheath avatar Dec 12 '23 12:12 tmheath

Just got back to this after much time. In the current binary release for Windows the problem is solved. There is no longer any performance hit due to moving the cursor outside the border of the window itself and there is only minor usage increase when moving the cursor over the window (albeit even if another window is in front). Closing this issue.

tmheath avatar May 23 '24 14:05 tmheath