similar to: unexpected memory.limit on windows in embedded R

On Thu, Jan 15, 2015 at 3:55 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > Just wanted to start a discussion on whether R could ship with more > appropriate GC parameters. I've been doing a number of similar measurements, and have come to the same conclusion. R is currently very conservative about memory usage, and this leads to unnecessarily poor performance on

>>>>> Peter Haverty <haverty.peter at gene.com> >>>>> on Mon, 19 Jan 2015 08:50:08 -0800 writes: > Hi All, This is a very important issue. It would be very > sad to leave most users unaware of a free speedup of this > size. These options don't appear in the R --help > output. They really should be added there. Indeed,

Dear R-ers, While browsing the R sources, I found the following piece of code in src\main\memory.c: static void reset_pp_stack(void *data) { R_size_t *poldpps = data; R_PPStackSize = *poldpps; } To me, it looks like the poldpps pointer is a nuissance; can't you just cast the data pointer and derefer it at once? Say, static void reset_pp_stack(void *data) { R_PPStackSize = *

Dear R developers, The slow performance of serializing to a raw vector on Windows is an issue that has appeared in this list before. It appears to be due to the frequent use of realloc from the resize_buffer method in serialize.c. I suggest a more granular, but still incremental, re-allocation of memory. For example change near the top of resize_buffer to: R_size_t newsize = needed + 65536 -

Hi everyone, I'm trying to import .sps (SPSS portable file) file. the read.spss function (library foreign) doesn't allow to import such files. should I import in spss and then save as sav file? there is not other solutions available? what I mostly like from spss file is that they have variable labels. want is really wish to keep are the variable.labels from the spss file; so, if there is a

Hi All, This is a very important issue. It would be very sad to leave most users unaware of a free speedup of this size. These options don't appear in the R --help output. They really should be added there. Additionally, if the garbage collector is working very hard, might it emit a note about better setting for these variables? It's not really my place to comment on design philosophy,

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

Just wanted to start a discussion on whether R could ship with more appropriate GC parameters. Right now, loading the recommended package Matrix leads to: > library(Matrix) > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 1076796 57.6 1368491 73.1 1198505 64.1 Vcells 1671329 12.8 2685683 20.5 1932418 14.8 Results may vary, but here R needed 64MB of N cells and 15MB

When large calls cause errors R may stall for extended periods.? This is particularly likely to happen with `do.call`, as in this example with a 24 second stall: ??? x <- runif(1e7) ??? system.time(do.call(paste0, list(abs, x)))? # intentional error ??? ## Error in (function (..., collapse = NULL)? : ??? ##?? cannot coerce type 'builtin' to vector of type 'character' ??? ##

Dear All, at the moment I am using R for calculations of large databases. Unfortunately, R only manages to complete certain operations at some times, and not at others. I usually get the error message "cannot allocate vector of size XX" I am using the 64-bit version with Windows 7. While my computer has 8 RAM, I do have a feeling that R cannot use all of it. Searching online, I

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a

The Rprofmem facility is currently enabled only if the configuration option --enable-memory-profiling is used. However, the overhead of having it enabled is negligible when profiling is not actually being done, and can easily be made even smaller. So I think it ought to be enabled all the time. I've attached a patch doing this, which also makes a number of other improvements to Rprofmem,

I have a dataframe df <- df <- data.frame (Revenue = c("100", "300", "500"), Brand = c("Apple", "HP", "Lenovo") ) how can i create a vertical barplot that displays brands in x-axis and Revenue in Y-axis [[alternative HTML version deleted]]

We also have a few other suggestions and wishes about backtrace storage and display on the one hand, and display of constructed calls on the other hand. Perhaps it would be better to open a different wishlist item for traceback() to keep the discussions focused? FWIW I think deparsing backtraces lazily is a great idea. Displaying 1 line per call by default in interactive sessions, while being

I'm picking up this 5-year old thread. 1. About the four memory allocations without a stacktrace I think the four memory allocations without a stacktrace reported by Rprofmem(): > Rprofmem(); x <- raw(2000); Rprofmem("") > cat(readLines("Rprofmem.out", n=5, warn=FALSE), sep="\n") 192 :360 :360 :1064 :2040 :"raw" are due to some

Allocating many small objects triggers numerous garbage collections as R grows its memory, seriously degrading performance. The specific use case is in creating a STRSXP of several 1,000,000's of elements of 60-100 characters each; a simplified illustration understating the effects (because there is initially little to garbage collect, in contrast to an R session with several packages

Dear UseRs, I'm using the library maps. I'm drawing maps of Italy. The map available for this library were prepared around *1989*: "This italy database comes from the NUTS III (Tertiary Administrative Units of the European Community) database of the United Nations Environment Programme (UNEP) GRID-Geneva data sets. These were prepared around *1989*" [cited:

? Wed, 29 Nov 2023 00:29:49 +0000 Livio Beqiri <liviob at live.com> ?????: > how can i create a vertical barplot that displays brands in x-axis > and Revenue in Y-axis What have you tried? If you're not currently studying R with an instructor (who should be contacted with basic questions like this instead; see the posting guide at [1]), I can recommend a free book by A. Shipunov

This is probably best viewed in the context of other issue with displaying calls, such as issues arising from calls constructed in non-standard evaluation contexts. Might be good to move to a wishlist item in bugzilla. Best, luke On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote: > When large calls cause errors R may stall for extended periods.? This > is particularly likely to happen

Better to add this to the wishlist item. This all needs to be looked at together, and nothing is likely to happen until after vacation/conference season. It will disappear from everyone's radar if it is just in R_devel. Best, luke On Sun, 14 Jul 2019, brodie gaslam wrote: > Luke, thanks for considering the issue.? I would like to > try to separate the problem into two parts, as I