From ggrothendieck at gmail.com  Sat May 30 20:31:18 2009
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Sat, 30 May 2009 14:31:18 -0400
Subject: [Rd] degraded performance with rank()
In-Reply-To: <ccac61760905300758y456d11c7i56f481ebb0e99063@mail.gmail.com>
References: <ccac61760905300758y456d11c7i56f481ebb0e99063@mail.gmail.com>
Message-ID: <971536df0905301131g4a15fd6eq65de8889304c3074@mail.gmail.com>

On Sat, May 30, 2009 at 10:58 AM, Tim Bergsma <timb at metrumrg.com> wrote:
> Hi.
>
> I'm maintaining a package that creates an object that is essentially a
> classed version of numeric. ?I updated recently from 2.7.1 to 2.9.0,
> and merges involving my class suddenly took a huge performance hit.
> I've traced the problem to something near rank(). ?From NEWS, it seems
> rank() etc. changed in 2.8.0. ?Methods for xtfrm() are supposed to
> help, but I've had no success. ?There was some chatter about this in
> the archives back in Sept 08 (though apparently regarding S4), with a
> suggestion that it is related to `[.` methods. ?That has been my
> experience. ?In the toy example below, the problem disappears if
> `[.my` is not defined. ?Under R 2.7.1 on Mac, both cat() statements
> take the same amount of time, and that time depends very little on the
> length of x. ?Under 2.9.0, the classed version takes much longer, and
> the time grows (more than?) exponentially with length(x).
>
> Is there something I can do to xtfrm.my() or [.my(), etc. to restore
> the performance?
>
> Thanks in advance,
>
> Tim.
>
> rm(...deleted rest of line...

OUCH!!!

Please don't post code like that.  Someone may wipe out valuable
objects in their workspace.



[Rd] degraded performance with rank()
Gabor Grothendieck