From murdoch@dunc@n @end|ng |rom gm@||@com  Mon Feb  4 15:32:11 2019
From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch)
Date: Mon, 4 Feb 2019 09:32:11 -0500
Subject: [Rd] Inefficiency in df$col
In-Reply-To: <20190204142013.GA10151@mail.cs.toronto.edu>
References: <mailman.48126.3.1549278001.57232.r-devel@r-project.org>
 <20190204142013.GA10151@mail.cs.toronto.edu>
Message-ID: <881488b4-7225-1f0b-bde5-9ceed235533d@gmail.com>

On 04/02/2019 9:20 a.m., Radford Neal wrote:
>>> I think you might want to just delete the definition of $.data.frame,
>>> reverting to the situation before R-3.1.0.
>>
>> I imagine the cause is that the list version is done in C code rather
>> than R code (i.e. there's no R function `$.list`).  So an alternative
>> solution would be to also implement `$.data.frame` in the underlying C
>> code.  This won't be quite as fast (it needs that test for NULL), but
>> should be close in the full match case.
> 
> I maybe wasn't completely clear.  The $ operator for data frames was
> previously done in C - since it was done by the same primitive as for
> lists.  In R-3.1.0, this was changed - producing a massive slowdown -
> for the purpose of giving a warning on partial matches even if the
> user had not set the warnPartialMatchDollar option to TRUE.  In
> R-3.1.1, this was changed to not warn unless warnPartialMatchDollar was
> TRUE which was the PREVIOUS behaviour.  In other words, this change
> reverted the change made in R-3.1.0.  But instead of simply deleting
> the definition of $.data.frame, R-3.1.1 added extra code to it, the
> only effect of which is to slightly change the wording of the warning
> message from what is produced for any other list, while still retaining
> the massive slowdown.
> 
> There is no need for you to write $.data.frame in C.  You just need
> to delete the version written in R.

Sorry, I did misunderstand.  Thanks for the clarification.

But if the "You" in your last sentence meant me, it needs to be "They": 
I am not a member of R Core and can't make any changes to the sources.

Duncan Murdoch



[Rd] Inefficiency in df$col
Duncan Murdoch