Re: Data_Make_Struct Considered Dangerous?

ts <decoux@xxxxxxxxxxxxxx> wrote:
-------------------------------------
> W>     ....
> ptr-> data2 = Qnil;
> ptr-> data2 = Data_Make_Struct (cInner...);
> W>     ....

>  No, this is not the solution. If you make a right use of Data_Make_Struct
>  ptr->data2 == NULL before the call to Data_Make_Struct() and you can test
>  this in the mark functions. 
-------------------------------------

Well, I don't like to have "ptr->data2 = NULL" simply because I usually
use NULL for pointers and currently VALUE is unsigned long.  Also (see
below), I don't like to make mark functions too complicated, because they
are pure Ruby overhead.

-------------------------------------
> W>     1) NEVER use Data_Make_Struct.  Use Data_Wrap_Struct instead.
> W>     2) NEVER use Ruby's ALLOC.  Use, at least, C's malloc instead.

>  Don't say this : this is *stupid*

>  First learn how to use the ruby API, and remove *your* bugs in the source
>  of your extension before trying to say such stupidities.
-------------------------------------

This is not stupid at all.  One thing that I have learned from creating
C-Ruby interaction is, beside connecting Ruby to existing C libraries, the
only reason we want to write in C is for execution speed (especially for
the core software).  Yes, when we write in Ruby everything is nice: fewer
lines of code, no memory leaks, no segmentation fault.  However, the core
may be too slow to be written in Ruby.

What I have learned is, if we write in C in "the Ruby way" (writing Ruby
code in C), then the execution speed gain is not very spectacular.  I
observed that one of the primary overhead is Ruby gc, which is invoked
often in a dynamic environment, with all the mark function overhead.  So
my principle is, when we write in C, for execution speed purpose, STAY
AWAY FROM RUBY AS FAR AS POSSIBLE.  This includes memory allocation and
Ruby objects.  If some objects are supposed to stay, create them with
standard C malloc; in this way the gc doesn't need to bother them.  Also,
convert Ruby objects to C struct's as much as possible for the same
reason.  Only when it is absolutely necessary to interact with a user, we
have to create a Ruby object as an interface, where Data_Wrap_Struct plays
a role.  With this technique, I have been able to increase my code
efficiency from 222,000 events/sec to 312,000 events/sec.  Using all Ruby,
it is about 31,000 events/sec.

Therefore, the statements above are consistent with the principle of
staying away from Ruby as much as possible.  There is the Ruby way, there
is the C way, and there is the Ruby-C way. :)

Regards,

Bill