R devel - Sep 2014 - normalizePath is sometimes very slow for nonexistent UNC paths

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

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

On 07.09.2014 10:07, Richard Cotton 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)

It is an OS "problem": You r OS tries to find some and has to look 
around waiting for responses. Hence you run into timeouts. If the cached 
result says some does not exist, you are quick...

Best,
Uwe Ligges


> 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.
>