From karl at huftis.org  Wed Jan 26 14:37:08 2011
From: karl at huftis.org (Karl Ove Hufthammer)
Date: Wed, 26 Jan 2011 14:37:08 +0100
Subject: [Rd] match function causing bad performance when using
	tablefunction on factors with multibyte characters on Windows
References: <ihbko3$efs$1@dough.gmane.org> <ihkd01$bem$1@dough.gmane.org>
	<ihm9qq$9ej$1@dough.gmane.org>
	<96D7BCDC-2FCF-4FB6-BDE6-0A55DAB57DA5@r-project.org>
	<ihom50$312$1@dough.gmane.org>
Message-ID: <ihp81l$ucj$1@dough.gmane.org>

Karl Ove Hufthammer wrote:

> Anyway, do you think it?s worth trying to change the ?table? function the
> way I outlined in my first post?? This should eliminate the performance
> hit on all platforms.

Some additional notes: ?table? uses ?factor? directly, but also indirectly, 
in ?addNA?. The definition of ?addNA? ends with:

    if (!any(is.na(ll))) 
        ll <- c(ll, NA)
    factor(x, levels = ll, exclude = NULL)

Which is slow for non-ASCII levels. One *could* fix this by changing the 
last line to

  attr(x, "levels")=ll

But one soon ends up changing every function that uses ?factor? in this way, 
which seems like the wrong approach. The problems lies inside ?factor?,
and that?s where it should be fixed, if feasible.

BTW, the defintion of ?addNA? looks suboptimal in a different way. The last 
line is always executed, even if the factor *does* contain NA values (and of 
course NA levels). For this case, basically it?s doing nothing, just taking 
a very long time doing it (at least on Windows). Moving the last line inside 
the ?if? clause, and adding a ?else return(x)? would fix this (correct me if 
I?m wrong).

-- 
Karl Ove Hufthammer



[Rd] match function causing bad performance when using tablefunction on factors with multibyte characters on Windows
Karl Ove Hufthammer