XVector (version 0.12.0)

compact: Object compaction

Description

Compacting an object is modifying its internal representation in order to reduce its size in memory.

Usage

compact(x, check=TRUE, ...)
## Internal compact() support function. Not intended to be called
## directly:
xvcopy(x, start=NA, end=NA, width=NA, lkup=NULL, reverse=FALSE)

Arguments

x

For compact, the object to be compacted. compact accepts any R object. However, on most of them, compact won't do anything and will just return an object identical to x. See the Details section below.

For xvcopy, a SharedVector, XVector, SharedVector_Pool, or XRawList vector.

check

After compacting the individual slots of an S4 object, this argument is passed to `slot<-` when replacing the original value of a slot with the compacted value.

...

Arguments to be passed to or from other methods.

start, end, width, lkup, reverse

For internal use.

Value

An object equivalent to x but eventually smaller in memory.

Details

The internal reorganization of the object should be transparent to the user i.e. compact(x) should "look" the same as x, or, more precisely, x and compact(x) should be interchangeable anywhere in the user's code. However, because they have different internal representations, we generally don't expect identical(x, compact(x)) to be TRUE, even though most of the times they will, because there are only very few types of objects that compact actually knows how to reorganize internally.

compact is a generic function.

Here is how the default method works. By default compact(x) is obtained by compacting all the "components" in x. Only 2 kinds of objects are considered to have "components": lists (the components are the list elements), and S4 objects (the components are the slots). The other objects are not considered to have components, so, by default, compact does nothing on them. In particular, it does nothing on environments. Also the attributes of an object (other than the slots of an S4 object) are not considered to be "components" and therefore are not compacted.

Note that, in the absence of specialized compact methods that actually know how to reorganize an object internally, the default method would visit the tree of all the components, sub-components, sub-sub-components etc of object x without actually modifying anything in x. So of course, specialized compact methods need to be defined for the objects that can *effectively* be compacted. Otherwise the compact function would be equivalent to the identity function!

At the moment, 2 specialized compact methods are defined (in addition to the default method): one for XVector objects, and one for XVectorList objects.

See Also

XVector-class, XVectorList-class, subseq, object.size, save

Examples

## We illustrate the use of compact() on an XInteger vector (XInteger
## is one of the 3 concrete subclasses of the XVector virtual class):
x <- XInteger(500000, sample(500000))

## subseq() does NOT copy the data stored in an XVector object:
y <- subseq(x, start=41, end=60)
x@shared
y@shared  # same address
object.size(x)
object.size(y)  # same size

## compact() copies the data, but only the data actually "used" by 'y':
y0 <- compact(y)
y0@shared  # new address
object.size(y0)  # much smaller now!

## Compaction is particularly relevant when saving an object with
## external references like 'y':
yfile <- file.path(tempdir(), "y.rda")
save(y, file=yfile)
file.info(yfile)$size

y0file <- file.path(tempdir(), "y0.rda")
save(y0, file=y0file)
file.info(y0file)$size