Rob Muhlestein
1/3/2007 5:37:00 AM
khaines@enigo.com wrote:
> On Wed, 3 Jan 2007, wbsurfver@yahoo.com wrote:
>
> > I was told by someone that tried to write a daemon process in Ruby to
> > serve treaming audio files to multiple clients that it uses alot of
> > memory which made the web server usage too high. Too high meaning the
> > amount allocatable memory from a web service where you don't own the
> > web server and pay based on your usage etc. I was told threads in Ruby
> > are not native threads and that since Ruby doesn't have a virtual
> > machine that this was also part of it. I am just trying to find out
> > more, and if what I said makes sense to other people here. Also, would
> > using Perl be different if this was the case ?
>
> There are WAY too many variables in the above information.
>
> You can run a Ruby daemon in a few MB of RAM, depending on what it is
> doing.
>
> If the goal is to minimize RAM usage, one is better off using something
> other Ruby or Perl, though. C might be good. Still, one can pack a lot
> of functionality in a fairly small (relative to the RAM in a modern
> system) memory footprint.
Usually if a daemon process is holding onto memory it isn't the
language's fault. Usually it is from the application on deferencing and
finalizing variables and such. If you can rule that out, then the
libraries used are next suspect, then (and really only then) should
the finger be pointed at the language.
If your app involves audio streaming there is a good bet it is
dynamically allocating a rather large memory buffer in order to keep
the bitstream rate high. That might be configurable depending on the
app, which is where I'd suggest focusing your attention rather than the
language.