Socket#recv into a buffer

Is there any reason why Socket#recv can’t take an optional buffer
argument the way IO#read does?

Otherwise, Socket#recv is always allocating strings, hence burdening GC.

I saw about a 20% improvement by using #read instead of #recv in some
socket code, but of course the unbuffered vs. buffered difference comes
into play there too.

Joel VanderWerf wrote:

Is there any reason why Socket#recv can’t take an optional buffer
argument the way IO#read does?

Otherwise, Socket#recv is always allocating strings, hence burdening GC.

I saw about a 20% improvement by using #read instead of #recv in some
socket code, but of course the unbuffered vs. buffered difference comes
into play there too.

Sounds like it would make a good patch. I think the reason it’s not is
that [afaik] ruby typically doesn’t have default lengths for
strings…i.e. if recv returns less than the desired number of bytes,
ruby ‘tends’ to return a string of exactly that length [and that much
memory allocated] so…in our hypothetical example above, it
should…leave it still large? [i.e. it would require string itself to change].
That being said, you CAN have a string with extra nulls in it
“abc\0def” and that’s a valid string, so maybe recv_into_string could
just write out something like that…
thoughts?
-R

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs