xml-dev - Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal

["Mark L. Fussell" <fussellm@alumni.caltech.edu>]

On Sun, 14 Dec 1997, Peter Murray-Rust wrote:
> The following assertions are based on ignorance and hearsay...
> 
> As I understand it, if Java wants a method in a class, it loads the whole
> class into the virtual machine.  Therefore if you have a large complex
> class you have a constant large overhead in terms of (a) HTTP connections
> (b) JVM space. 

Actually, for a given amount of functionality there is more overhead to
have it divided into multiple files than in a single file.  First, the
number of HTTP connections will go up as the number of files goes up and
HTTP connection setup time is significant.  Second, the size of a '.class'
file is usually about evenly divided between the symbol table (containing
method names) and the actual method bytecodes.  If you split a file you
need to duplicate the inter-file method-name symbols.  You may also need
to duplicate some helper methods.  Third, to resolve a class (which is
required to use its methods) you need to resolve all of the types that the
class [as a whole] uses, which will cause you to load in any related
classes.  This makes it unlikely that only a single smaller class would be
loaded if a big class is divided.  [Typing to interfaces instead of
classes reduces this chaining problem.]

So for XMLParser, which is currently ~24K, splitting it into (say) four 7K 
files (6K+1K repetition) will probably increase the overall download time 
noticeably (>20%).  A compressed JAR would remove all of these issues but 
David said he wants Aelfred to be backward compatible, so a single 
'class' file is a good (probably the best) approach.

>..I have a number of very large classes (e.g. > 100 member
> functions, some quite crunchy) so I have been thinking of doing the exact
> reverse to DavidM - i.e. splitting up my classes into smaller bits.  Thus
> my MOLNode implements Drawable routines, Linkable (XLL), Editable,
> Validatable at least. If I have a very simple application it will still
> download all these functions (am I right?) and also keep them in the JVM so
> long as there is a re ference to an object of the class (am I still right?) 

Yes, class objects and their code are maintained until there are no
references to the class object (and instances are obviously one of those
references).  It is definitely a good idea to compose larger classes
(frequently the root domain objects) out of more focused pieces and
loosely connect them through delegation interfaces.  It is also good to
seperate presentation (everthing but validation above) from the core
information of the model.  This is sometimes hard to remember for
information systems and is certainly more difficult when you view you
information as inherently display-oriented (i.e. "documents"). 

> So I am thinking of splitting these into smaller chunks, such as
> DrawableMethods, etc which don't need to be loaded if not used.  Would the
> same apply to AElfred?  Thus if you had two chunks - DTD.class and
> Instance.class (or whatever) and the document instance had no DTD, you'd
> never need to load the DTD class, right?

But AElfred may need to use either at potentially any time. It is very
likely that a reference to the DTDParser.class would crop into the
InstanceParser.class and make it necessary to load both.  I would
certainly think it is another significant constraint to try to manage
avoiding any of these cross-references, even if the DTD and the rest of
the instance are conceptually well seperated. 

> I would assume it's possible to re-route the client to a non-JAR applet if
> required.

This would be up to the deploying applet maker.  Also, generally it is
best to JAR everything together that will be needed together so this would
be a different (larger) JAR than just an Aelfred specific JAR. 

That does lead me to a question: David, are you assuming that XmlParser is
always standalone?  If someone packages it with their application/applet
it is only about 11K in a compressed JAR so you are pretty close to your
size design goal from that pespective. 

--Mark
mark.fussell@chimu.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)