How I spent two weeks hunting a memory leak in Ruby (2015)
1–10 of 71 posts
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#2A little worrisome that the fix hasn't been merged. (edit: it's been fixed)
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#3A little worrisome that the fix hasn't been merged. (edit: it's been fixed)
Did you get all the way to the end of the blog post?
"Update on 2015/09/29. Redcarpet fix has been released."
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#4There is no reason for using native extensions in scripting languages like Ruby when program load is pretty low (especially when they are used for performance reason, not binding).
Great insight, though. Author described this experience as it was a great venture... in hindsight I suppose :-)
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#5Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#6That is fantastic dedication to finding the source of the memory leak. I'm not sure I'd have quite the devotion or expertise to track that one down.
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#7There is no reason for using native extensions in scripting languages like Ruby when program load is pretty low (especially when they are used for performance reason, not binding). Great insight, though. Author described this experience as it was a great venture... in hindsight I suppose :-)
> when program load is pretty low
The leak was in a gem.
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#8About the patch at https://github.com/vmg/redcarpet/pull/516/files, couldn't the update simply have been the following?
- return Data_Wrap_Struct(klass, rb_redcarpet_rbase_mark, NULL, rndr);
+ return Data_Wrap_Struct(klass, rb_redcarpet_rbase_mark, xfree, rndr);Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#9There is no reason for using native extensions in scripting languages like Ruby when program load is pretty low (especially when they are used for performance reason, not binding). Great insight, though. Author described this experience as it was a great venture... in hindsight I suppose :-)
I'd say it's appropriate for anything in the critical path - talking to databases being the only major thing that comes to mind. I agree that a native extension for markdown parsing is way overkill.
Stick with pure-language extensions (they're so much easier to work with!) until you can measure and quantify the cost and benefit of switching.
Re: How I spent two weeks hunting a memory leak in Ruby (2015)
#10There is no reason for using native extensions in scripting languages like Ruby when program load is pretty low (especially when they are used for performance reason, not binding). Great insight, though. Author described this experience as it was a great venture... in hindsight I suppose :-)
> when program load is pretty low The leak was in a gem.
Gem is still library albeit its name.