[Rd] normalizePath is sometimes very slow for nonexistent UNC paths

[Matt Denwood]

Maximum 0.02022958 seconds out of 10^6 runs for me, so no obvious problem on OS X 10.9 (Snow Leopard build).

Matt


> library(microbenchmark)
> (timings <- microbenchmark(
+  normalizePath("\\\\some/network/drive", mustWork = FALSE),
+  times = 1e6,
+  unit  = "s"
+ ))
Unit: seconds
                                                          expr       min
 normalizePath("\\\\\\\\some/network/drive", mustWork = FALSE) 8.877e-06
        lq    median       uq        max neval
 9.428e-06 9.621e-06 9.86e-06 0.02022958 1e+06

> sessionInfo()
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] graphics  grDevices utils     datasets  stats     methods   base     

other attached packages:
[1] microbenchmark_1.3-0

> .Platform
$OS.type
[1] "unix"

$file.sep
[1] "/"

$dynlib.ext
[1] ".so"

$GUI
[1] "AQUA"

$endian
[1] "little"

$pkgType
[1] "mac.binary"

$path.sep
[1] ":"

$r_arch
[1] ""


On 07 Sep 2014, at 10:07, Richard Cotton <richierocks at gmail.com> wrote:

> I'm having an issue with occasionally slow-running calls to
> normalizePath.  If the path is a non-existent UNC path, then
> normalizePath sometimes takes 6 or 7 seconds to run, rather than its
> usual few microseconds.  My big problem is that I can't reliably
> reproduce this across machines.
> 
> The example below generates one or two slow runs out of 10000 on my
> Windows machine. I haven't been able to generate slow runs on my Linux
> machine, though I've had problems with slow running examples submitted
> to CRAN that I suspect may be caused by this.
> 
> library(microbenchmark)
> (timings <- microbenchmark(
>  normalizePath("\\\\some/network/drive", mustWork = FALSE),
>  times = 1e4,
>  unit  = "s"
> ))
> boxplot(timings)
> 
> Please can a few people run this code and see if they can reproduce the issue.
> 
> It isn't clear to me whether this is a bug in R or an underlying OS or
> network problem.
> 
> -- 
> Regards,
> Richie
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel