Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
 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@c... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
