similar to: Suggestion for serialization performance improvement on Windows

problem of the very large memory require by the Sign extension. --- R-2.5.0.orig/src/main/serialize.c 2007-03-27 01:42:08.000000000 +0900 +++ R-2.5.0/src/main/serialize.c 2007-06-25 00:48:58.000000000 +0900 @@ -1866,7 +1866,7 @@ static void resize_buffer(membuf_t mb, int needed) { - int newsize = 2 * needed; + size_t newsize = 2 * needed; mb->buf = realloc(mb->buf,

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 All, I'm linking R from another application and embedding it as described in the R-exts manual, i.e. with initialization done via Rf_initEmbeddedR. While everything works the same as in standalone R for Linux, under Windows I found a difference in the default memory.limit, which is fixed to 2GB (both win32 and win64) - compared to a limit in standalone R of 3.5GB for win32 and 16GB on

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' ??? ##

Hi Rich, This is v5 series to add support for resizing MBR logical partitions. please review. Thanks! changes to v4: 1. add support to resize extended partition (--resize or --expand extended partition) 2. fix the problem of deficit of 512 bytes when expanding a logical partition (this problem can be reproduced in v4 by only expanding a logical partition, without resizing any other

Hi Rich, This is rebase of v5 series. Meanwhile, I found a bug when shrinking partitions, and the fix is incuded in this version (patch 2). Regards, Hu changes to v4: 1. add support to resize extended partition (--resize or --expand extended partition) 2. fix the problem of deficit of 512 bytes when expanding a logical partition (this problem can be reproduced in v4 by only expanding a

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

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v2: 1) Add 3 variables to describe relationship of logical and extended partitions: - partitions flat list of primary partitions (as now, the global

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,

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v3: 1) rewrite partitions/logical_partitions/extended_partition section by the comments from Rich and Pino. 2) in 03/11 introduce logical_align for

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v4: rebase on upstream. v3: 1) rewrite partitions/logical_partitions/extended_partition section by the comments from Rich and Pino. 2) in 03/11

In current virt-resize, only primary partitions(including extended partition) are supported. They are collected in an array for resize operations. Logical partitions are not supported. This series add support for resizing logical partitions. v4: rebase on upstream. v3: 1) rewrite partitions/logical_partitions/extended_partition section by the comments from Rich and Pino. 2) in 03/11

The original implementation utilies select(). In Linux select() typically supports up to 1024 file descriptors. This can be a problem when user tries to boot up many guests. Switching to poll() has minimum impact on existing code and has better scalibility. Up to 8192 file descriptors are supported in the current implementation. Signed-off-by: Wei Liu <wei.liu2@citrix.com> ---

To get this out first: I'd love to have a way to serialize machine-IR! I often spend a lot of time trying to create .ll files in a way that the machine-IR still looks a certain way when it finally hits the relevant passes in codegen. It would be so much easier to just specify the machine IR immediately before the pass I'm interested in. For that use case it is worth keeping the following

On Tue, Jul 15, 2014 at 09:01:47AM +0100, Richard W.M. Jones wrote: > The answer is I don't know. But there are a few things you can try: > > (1) Most importantly, enable tracing (export LIBGUESTFS_TRACE=1) and > get a list of operations that are performed in the order they are > performed. This is vital for debugging this. > > (2) When the error happens, run