search

driusan / de

A Programmer's Text Editor
MIT License
424 stars 25 forks source link

memory leak #6

Closed us3r64 closed 8 years ago

us3r64 commented 8 years ago

it looks like you have some memory leaks in there:

de

driusan commented 8 years ago

Ouch, that definitely looks worse than it should. I'm trying to reproduce and can't get it higher than around 230mb. I'll have to find a good valgrind-like tool for Go..

Some questions to reproduce in case I need to track it down manually:

  1. How big is the file you're editing?
  2. How long was the editor session open? (My typical work flow involves quitting to a shell pretty often, which might explain why I didn't see this..)
  3. What OS, in case it's a bug in a downstream driver? (Looks like Mac?)
  4. Were you doing a lot of editing or just browsing source code? If editing: inserting or deleting? If browsing: about how many files had you gone through to get the memory usage this high?
  5. What version of Go are you using? (I think there's been pretty significant improvements to the GC in the last couple releases..)
us3r64 commented 8 years ago
  1. file size 76KB - 2838 lines
  2. the memory goes up to 6 GB right away after opening the file and pressing j a few times
  3. OS X 10.11.5 (15F34)
  4. just browsing, moving up and down (j,k), 1 file opened
  5. go version go1.6.2 darwin/amd64
driusan commented 8 years ago

I don't think it's a memory leak. What I'm seeing with smaller files is that when I move around it takes a few renders (and j,k is triggering the render code since it needs to move where the cursor is drawn) before the Go GC kicks in.

I'm afraid to ask what you're doing with 76kb of source code in a single file (the biggest one in de is ~3kb), but I think writing the text in it to an RGBA image that can be drawn on the window is so large means that 5-6x that is getting out of hand and (and probably swapping before the GC has a chance to kick in?)

What I'll have to do is make sure the rendering code is smart enough to only render the part of the file that's being drawn to the screen so that it's invariant of file size, which is something I've been meaning to do anyways, but with my smaller files it's been fast enough to not be a significant issue.

Is the code that you're viewing open source or available somewhere that I can use as a test case?

Komosa commented 8 years ago

Try this one: https://github.com/shurcooL/Conception-go/blob/665082e232068d054ec53e3d43680b0f8be2b456/main.go

us3r64 commented 8 years ago

Same issue. Looks that with file size memory used grows exponentially.

driusan commented 8 years ago

I just commited something that should fix this. Can you try it and let me know if it worked?

The speed of the rendering (and responsiveness of the keyboard as a result) is still proportional to the file size, but now it's only allocating an image the size of the window, so the memory usage should be constant (or at least a function of the window size instead of the file size..)

us3r64 commented 8 years ago

Same behavior using the main.go file from @Komosa

driusan commented 8 years ago

@us3r64 Did you update to the latest code? The excess memory consumption should be fixed in the latest version if you update with go get -u github.com/driusan/de, but yes, @Komosa's linked is big enough to have broken with the old version.

us3r64 commented 8 years ago

Looks to be fixed now.