marbru@auto-trol.UUCP (Martin Brunecky) (12/01/89)
One of the most often discussed "weaknesses" of the Xt based
applications is a substantial memory usage, mostly accounted for
by the size of widget instances. Gadgets and "flat" widgets are
one of ways to cope with the problem. Here I suggest another
approach:
Very often, a significant portion of the widget instance record
is identical for several instances of the same or multiple
classes. For example, Motif 3D/shading resources are typically
identical for almost all instances in the entire application,
even though there may be several "groups" and few special cases.
Hence, a read-only sharing of such "subresources" or
"value-sets" would provide significant memory savings. What is
needed is a caching/cloning mechanism similar to the one used for
the Xt graphics context (GC) handling. Mechanism allowing to ask
for a pointer to a data structure containing particular
value-set. If such a value-set already exists, the requestor
will be given a pointer and the reference count for value-set
will be incremented. If not, the new value-set will be created.
To change any value in a set, the requestor will release the
"old" set and request a new one, containing a changed value. The
requestors will be responsible for releasing shared values -
again significant similarity to the GC mechanism.
Each value-set may be identified by a "set identifier" - an
opaque value inquired once for each set, typically by the widget
class part initialization. The set identifier allows separate
caching for each "values set". The generic mechanism will be
available for any data used in the toolkit, such as resource
blocks, private read-mostly data etc.
One may suggest that a very similar mechanism already exists in a
form of the XtConvert resource conversion caching scheme.
However, there is a substantial difference: resource conversion
does NOT keep track of how many instances of the conversion are
used, and does NOT release any allocated memory when the data are
not used anymore.
Proposed mechanism does not present any user-level compatibility
problems. For example, if the Motif widget set elects to move
their 3D/shading data into a shared data set, it can be done
transparently to the user, using the R4 extensions to the
intialize and set/getvalues. Obviously, the widget internal code
will have to change. But the savings, in this particular case
over 40 bytes per any instance, can be significant. ,BL
Sugggested interface:
typedef void* DatasetID;
DatasetID XtDefineDataset ( Cardinal size );
Initializes read-only caching for a particular data type/size.
It is assumed all the data cache blocks are aligned for the
worse case - double.
void* XtAllocDataset ( DatasetID set, void* data );
Allocates a shared, read-only copy of the "data". If the "data"
already exists, the pointer to this data is returned and a
reference count increased. Otherwise, the new cache element
containing copy of ther "data" is created.
void XtFreeDataset ( DatasetID set, void* ptr );
Releases a copy of data previously allocated by the XtAlocDataset,
ptr is a pointer returned by a previous call to XtAlocDataset.
If the reference count for a particular dataset reaches zero,
the memory is released to the system.
###############################################################################
Martin Brunecky, Auto-trol Technology Corporation,
12500 North Washington Street, Denver, CO-80241-2404
(303) 252-2499 ncar!ico!auto-trol!marbru
--
###############################################################################
Martin Brunecky, Auto-trol Technology Corporation,
12500 North Washington Street, Denver, CO-80241-2404
(303) 252-2499 ncar!ico!auto-trol!marbru