Prof Brian Ripley wrote:
Let me repeat: what is happening for me in the equivalent of your
35.589 - 1.18 seconds is that R is waiting for my OS to read its discs
(and they can be heard chuntering away). As the R process is not
runniing at those times, the profiler is not running either (on a
Let me repeat: what is happening for me in the equivalent of your
35.589 - 1.18 seconds is that R is waiting for my OS to read its discs
(and they can be heard chuntering away). As the R process is not
runniing at those times, the profiler is not running either (on a
Unix-alike: on Windows the
Prof Brian Ripley wrote:
On Tue, 3 Mar 2009, Romain Francois wrote:
Prof Brian Ripley wrote:
The caching is in the disc system: you need to find and read the
package metadata for every package. AFAIK it is not easy to flush
the disc cache, but quite easy to overwrite it with later reads.
(
On Tue, 3 Mar 2009, Romain Francois wrote:
Prof Brian Ripley wrote:
The caching is in the disc system: you need to find and read the package
metadata for every package. AFAIK it is not easy to flush the disc cache,
but quite easy to overwrite it with later reads. (Google for more info.)
Tha
Prof Brian Ripley wrote:
The caching is in the disc system: you need to find and read the
package metadata for every package. AFAIK it is not easy to flush the
disc cache, but quite easy to overwrite it with later reads. (Google
for more info.)
Thanks for the info, I'll try to find my way wi
The caching is in the disc system: you need to find and read the
package metadata for every package. AFAIK it is not easy to flush the
disc cache, but quite easy to overwrite it with later reads. (Google
for more info.)
If you are not concerned about validity of the installed packages you
c
