Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Message-ID: <39AABFCA.5530F7C2@infoinsomniax.com>
Date: Mon, 28 Aug 2000 15:38:50 -0400
From: "Ilya A. Kriveshko" <ilya@infoinsomniax.com>
Organization: InfoI Insomniax, Inc.
MIME-Version: 1.0
To: cocoon-users@xml.apache.org
Subject: Re: Aha! got it! 64k limit(was: new version of the sql logicsheet
 under
 development)
References: <F46wEUJlWZO8x96PnPl00000a68@hotmail.com>
 <39AAA83C.91E16072@apache.org>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit


Ricardo Rocha wrote:

> > This will help a lot with large chunks of literal data. But there is still a
> > theoretical limit, even then - it's just that with this, I would have
> > thought that limit would be far less likely to be reached.
>
> We've hit the 64k limit mostly because of the way we inline strings,
> but if we separate data from code (and if we use Ulrich's common-case
> "synthetic" methods), we should be able to raise this limit
> considerably.

I seriously doubt that the strings that are inlined in the source code stay
inlined in the bytecode. Any self-respecting compiler would move them
into static memory, so most likely they become anonymous static final
class variables. I wouldn't expect long strings to be the problem.
(Actually, I tried using CFParse, and it shows all the strings from my
classes stored in a constant pool.)

So, the 64k problem *is* caused by the code itself...

So, since the compiler is going to do that anyway, I don't think there is
a need to explicitly make static string variables, unless you know you are
going to reuse the values in several places or for the sake of producing
pretty code. The generated code doesn't have to look pretty, since it is
not meant to normally be seen by the programmer.

The more immediate problem is taming the long spaghetti of
instructions that are building the document tree. On the surface,
it seems to me that building fragments of the tree, then serializing
them in a separate file for later use is a good solution.

However, before making a decision, one must analyze the
performance implications of either option. It seems to me that
anything that is done to fix the 64K problem will degrade the
performance, compared to the way it is implemented now, some
solutions more so than others. That, I think, also needs to be
considered.
---
Ilya.