How I spent two weeks hunting a memory leak in Ruby (2015)

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by rgtk on Tuesday September 13, 2016 @04:20PM (#12491875)

There 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 :-)

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by scott_s on Tuesday September 13, 2016 @04:41PM (#12492036)

Your criticism really applies to the gem authors, which to me, does not make sense. If I, as a library developer, want my library to be used on the critical path in heavy-load situations, and the library is for a language like Ruby, I'm going to figure out which part of my library are the performance critical parts, and implement them in a native language.

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by haimez on Tuesday September 13, 2016 @08:33PM (#12493420)

You would think that you (in this case, "you" == "average library author in the ruby ecosystem") would, but you won't. I'm fairly confident the problem is similar, but likely worse in the javascript ecosystem.

Necessity is the mother of invention, and when you're the first person to notice a memory leak, you're on your own.

Both ecosystems tout the low barrier to entry as a great benefit, but memory leaks, mostly benign inefficiencies, and poor algorithmic efficiency becomes at least par for the course if not a crippling liability when reality hits your application like a freight train (or say a 2 order-of-magnitude spike).

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by yxhuvud on Tuesday September 13, 2016 @04:33PM (#12491972)

The reason for the binding can be that no-one can be assed to reimplement the functionality. It is not as if anyone expect the scripting languages to implement their own versions of openssl.

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by teej on Tuesday September 13, 2016 @04:25PM (#12491920)

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.

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by mnarayan01 on Tuesday September 13, 2016 @04:24PM (#12491906)

> when program load is pretty low

The leak was in a gem.

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by rgtk on Tuesday September 13, 2016 @04:29PM (#12491947)

Gem is still library albeit its name.

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by mnarayan01 on Tuesday September 13, 2016 @04:58PM (#12492168)

1. AFAIK it's the most popular Markdown gem around (ref. https://www.ruby-toolbox.com/categories/markup_processors) so using it in a project is more "default" than it is "optimization".

2. With over 10M downloads, I assume at least some of them spend large percentages of time using it.

3. It's Markdown; replicating the idiosyncrasies of SmartyPants (https://daringfireball.net/projects/smartypants/) in a different language is not something many people are going to want to do.

I'm not saying that people should or should not use Redcarpet; just that it's unlikely that anyone engaged in "premature optimization" here.

[ Parent | on HN ]

Re:How I spent two weeks hunting a memory leak in Ruby (2015) by amalag on Tuesday September 13, 2016 @04:49PM (#12492099)

Now that people are figuring out how to do this in Rust things should get a lot better.

[ Parent | on HN ]