RE: A truth? patch + benchmarks

> From: Yukihiro Matsumoto 
...
> |> Unfortunately, there's no bit available for all objects.  All flag
> |> bits are used to represent NODEs' line number.
> |
> |To bad ... but maybe we might see something like it in 2.0? (or
> |even better body smatter cooks something up for the current
> |development line - maybe only replace the RTEST calls in the
> |crucial IF_NODE, WHILE_NODE ...  part?)
> 
> If it is really efficient, I think we can reserve a bit ot two for

One bit should be enough.  My tests indicate that for the current
Implementation this would have been efficient, but I obviously can
only guess, how this or a similar scheme, would fair in an interpreter
rewrite.   

> it.  But I want to know the secret of this magic.

Actually, I am not quite sure to what ``magic'' you are referring to
(which only seems fair, since my emails are usually incomprehensible;-).

If the ``magic'' is referring to my observed speedup of replacing 
most RTEST macro calls with an inlined function call (at least on
my windows machine this effect seems to be real), I really have 
to pass (besides making uneducated guesses) but I tend to think that 
this "compilation optimization artifact" is wedded to the current 
implementation (putting things in perspective, changing from VC6 to
VC7 has an even bigger impact on speed).

Just been curious (and pushy;-). I counted 26 ``T_VALUES'' in ruby.h,
so from my naive point of view it might be possible (after 
rearranging the ``T_VALUES'' a bit, eehm, <= 31) to free up the sixth
bit as a false/true bit. Of course, I tried this and did not see any
obvious ill effect (running ``make test''  and ``rubicon'' on cygwin)
- I guess that's what they call wishful thinking;-).  

My question is, what did I overlook this time?


/Christoph