Skip to content

--nsize and --vsize

9 messages · Douglas Bates, Nicholas Lee, Brian Ripley +3 more

Original
Brian Ripley
# 
Martin M has suggested I widen this discussion to R-devel, and
Views, please.

------------- Begin Forwarded Message -------------

Is is not time we increased the defaults a bit? As the base gets bigger
I hit 200k cons cells rather frequently. And 2Mb of heap seems low
compared to 3Mb of cons cells and 1.8Mb for the R binary.

How little memory do people have these data?  Except possibly on Windows
and old teaching labs I would have thought using 15Mb default for R
was very reasonable, which is about

--vsize 6Mb --nsize 300k

On Solaris that gives:

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
 9308 ripley     1 -25    0   15M 8360K sleep   0:02  4.35% R.binary

as against the default

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
 9309 ripley     1 -25    0 9664K 6416K sleep   0:02  4.66% R.binary

and that extra user memory makes a lot of difference.


------------- End Forwarded Message -------------
Douglas Bates
# 
I would agree that:
 - it is reasonable to increase the default vsize and nsize
 - the default sizes should probably be architecture dependent
 - If possible, the default sizes should also be picked up from
   ${HOME}/.Renviron.  For example, look for R_VSIZE and R_NSIZE
   environment variables and use them

I think that 16M for vsize and 800k for nsize could be good global
defaults on many architectures.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Nicholas Lee
#
On 12 Apr 1999, Douglas Bates wrote:

            

      
      
      
    

        
If the environment variables where used (best solution), wouldn't it be
better to tell people in the memory exhaustion at startup warning message
that this option existed.  Rather than defaulting to a potentially
wasteful use of memory. 


Nicholas

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Mon, 12 Apr 1999, Nicholas Lee wrote:

        

            

      
      
      
    

        
Well, the flags exist now.  The `potentially wasteful' part is running out
of memory after a lot of work.  My comment is that at present the workspace
is less than half the total memory used: If you are going to use 10Mb
by default, why not use 15?

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
Based on the discussion so far, I have committed changes to 
`Version 0.64.0 Patched' that

  Uses R_NSIZE and R_VSIZE if set.

  Allows --nsize and --vsize to override these.

  Retains the previous minimum settings (200k and 2M) but if the user sets
  nothing uses 250K and 6M.  (Those just about allow MASS+lme to be
  loaded.)

This is in system.unix.c, so Unix-only. (I see no reason not to so
this under Windows too, although there are other ways there).

The only snag I see is that there is no way to change this on an
installation-wide basis except to edit bin/R or include/Defn.h
and re-compile, but I guess that (especially the first) is safe enough.

Brian

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Prof Brian D Ripley <ripley@stats.ox.ac.uk> writes:

            

      
      
      
    

        
...

            

      
      
      
    

        
Isn't that essentially the original purpose of using a shell script
(Win/Mac notwithstanding)? If we want it even easier, we could have
bin/R doing something like

...
$R_ENV=${R_ENV:-$RHOME/site/Renviron.sh}
[ -x $R_ENV ] && source $R_ENV
$R_NSIZE=${R_NSIZE:-250K}
...

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Kurt Hornik
    

    

      
      #
    

  


  

          

      
      
      
    

        
Something like that, similar to forthcoming R `rc' files (now profile):

	system rc from R_HOME/VERSION/...
	site rc from R_HOME/site/.../Rrc
	user rc from ./.Rrc or ~/.Rrc

	system environ from R_HOME/VERSION/...
	site environ from R_HOME/site/.../Renviron
	user environ from ./.Renviron or ~/.Renviron

Of course, then we'd need options

	--no-user-env
	--no-site-env

and I think I'd maybe want (for 1.0)

	--no-user-file => --no-user-rc
	--no-site-file => --no-site-rc

or (maybe better) keep what we have and interpret it as `files' so that
neither rc no env file would be used.

-k

Btw, I'd use `-r' ...

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      Nicholas Lee
    

    

      
      #
    

  


  

      
On Tue, 13 Apr 1999, Prof Brian D Ripley wrote:

        

            

      
      
      
    

        
The flags exist, but in the adage of the lazy programmer, "less
keystrokes, means less RSI/bugs."   One nice option would be for R to probe
the size of the .RData file, and rather than dieing on you if it's too
large, giving you option of loading it with XX extra memory.

            

      
      
      
    

        
This is always going to be the case since R uses a static memory heap.
So the question arises; if the default is 15, why not 20...? 


The best solution would be for system wide config flags or ENVIRONMENT
variables, as this would allow people to set a memory usage policy given
the amount of library functions they have, general memory usage patterns,
and personal inclinations. 


Nicholas 

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Robert Gentleman
    

    

      
      #
    

  


  

      
Do we have a policy on checking for valid options?

In working on the warning system I tried to get S to
give a warning. So I went:

 options(object.size= -9)

 but it didn't, it exited in a rather confused state.

Is it the responsibility of the function retrieving the
option to set the value to something sensible. The user
can set them to any old thing but we will just use the
default (regardless of the state of options). Or do we
actively try to maintain the options in a "reliable state"?

As near as I can tell we currently do the former (some of the
time).



-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._