Re: Location of missing end

On Mon, 2004-10-11 at 03:24, trans. (T. Onoma) wrote:
> On Monday 11 October 2004 02:43 am, Markus wrote:
> | Thought?  Comments?  Aberrant test cases?
> 
> I am concerned with Ruby performance, not that it is a significant issue with 
> this particular patch, but just that all the little things add up.
> 
> I certainly would like Ruby to have such a feature, in fact I think it is the 
> first "RCR" I ever asked about. But perhaps it would be a good idea if it 
> were executed only upon -c ?
> 
> Just a thought,

     It's a reasonable thought (and a concern I share), but I don't
think it's appropriate in this case.  

      * The algorithm is O(n) on the amount of whitespace, with a very
        small k--just ++/--, ifs and stashing a few integers.*  If
        needed the overhead could be reduced by inlineing a few function
        calls, etc. to the point were doing it would be comparable to
        checking if it should be done.

      * The overhead, small as it is, is only at compile time, which is
        typically a small fraction of any ruby program that does
        significant work.

      * Empirically, for the ~50,000 line randomly generate test program
        from my free-form operators patch, the difference was too small
        to measure.  

Let me know if you think I've missed anything, or want to suggest
further tests.

-- Markus

* As implemented, there is one loop inside nextc() which could in be
refactored/removed by putting the counter in yylex, at a slight loss of
clarity/locality.  Also, there is a very minor hidden overhead in the
parser rules I used to implement block start keyword tagging (it
introduces an additional state transition).