Dear Mr. Matz,
Thanks for the information. Actually I am more concerned with the
execution overhead instead of memory overhead (I think memory is
relatively cheap these days); besides, as the entities are created and
destroyed so often, there will not be too many of them at any instant of
time.
In straight Ruby, one of my code has efficiency of about 30,000
events/second. When I transformed the core into C (so the input is still
in Ruby), the efficiency increases to about 130,000 events/second. I can
only think of either Ruby is indeed relatively efficient (compared to C),
or, because the core still has to deal with Ruby objects, the Ruby objects
are the bottleneck, which may include:
1) Object creation, initialization, and checking from time to time
(I have changed it from Data_Get_Struct to direct DATA_PTR)
2) Garbage collection, which runs occasionally but has to trace all
the Ruby objects
3) Ruby function call overhead, which includes "rb_funcall" and hash
access (which is not as fast as struct member access)
4) Parsing overhead (however, although my code is one big loop, I
guess this parsing overhead is one time only at the beginning)
This is why I am thinking on the lazy evaluation model.
Regards,
Bill
===========================================================================
Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> |Probably the most direct problem that I am currently facing is, I will
> |have many entities that will be created and destroyed so often (millions
> |of times) such as packets and events. If the user is not going to have
> |access to these entities, I can create efficient structures for them (even
> |probably manage the memory usage.) However, when a user is allowed to
> |interact with them, I am forced to make the packets and events as Ruby
> |objects (to be honest, I don't know how much overhead the Ruby objects
> |have as compared to straight C structs; I have not made comparison yet.)
> 5 words (20 bytes on int32 platforms) for each objects.
> matz.