performance issues
------------------

From the previous implementation of OMF, it's come to my
attention that XMI is not the most time-efficient storage
solution for enormous models. The previous implementation
took somewhere in the neighborhood of 20 seconds to load
a 2 MB XMI file. Ouch.

One reason for this was the handling of attributes during
parsing. We can expect a significant increase in loading
speed if we don't parse an element's attributes when the
model is instantiated. The basic idea is to build an
on-demand system into the object model. When the XMI file
is parsed, we can simply walk the DOM and create the
recognized objects and skip the rest. When an attribute
is programmatically accessed or altered, the persistence
layer could then resolve the value of the requested
attribute.

Of course, we can probably extend the on-demand scheme
to work for object creation too - especially since XMI
typically dictates nested XML elements for situations
involving composite aggregation (wholly owned objects
have nested elements). Since the composed objects are
accessible through a typical attribute accessor, we
could treat the creation of those objects the same way
we treat attributes.

There's at least one problem with this: alternative object
access techniques. If we use an extent to access instances,
then we won't know what objects are avaiable until they
have been loaded. An acceptable work-around for this would
be to start with the on-demand object creation scheme above,
and if the user requests objects through an extent, the
persistence layer would then finish creating all the objects.

Note that in either case, we still have to parse the
entire DOM tree. The question is how much performance do
we lose for creating the model elements on top of
creating the DOM elements.

Note that this technique requires the DOM tree to be
stored in conjunction with the model element. Fortunately,
we have some experience doing this - its how the first
OMF worked.

Another performance is the DOM implementation that we
use to handle the XML parsing. In the previous version,
we used Qt's DOM implementation because of its portability
benefits. However, a better solution might be to use an
optimized XML parser/DOM implementation like the one
used in libxml. Its generally accepted that libxml is
pretty quick and provides enough tree support (not quite
DOM, but close enough) that it could be used as a nice
in-memory document model.

Another performance issue that would probably help alot
is a set of customized parsers for models. By custom
parser, i mean metamodel-specific. In the previous version
of the OMF, I tried to build the worlds most generic
XMI parser - which actually worked. The only problem is
that it was "kind of" slow and some of the logic was
a little involved. This time, I think the right way
to go is to build a generic parsing framework with
metamodel-specific plugins. Maybe...

persistent identification
-------------------------

Two words: uuid, baby.

Why would we want to use uuid's to identify objects.
We could simply use a nice easy, model specific theme
like the ones described in older UML standards (a1, a2).
The only problem with that is that we lose intermodel
identity - unless we check the id of the model as part
of the object's id.

The uuid gets rid of this problem for us. Storing the
id as a uuid allows us to maintain object identity
across lots of different models. Anyway, I like it
better - even if the identifiers are a bit extensive.