It seems to me that parsing Gadget XML should be the least of our
worries, especially if you can insure that the content that's hitting
the browser only varies by country and language and view.
By moving the parentUrl to the hash I've been able to accomplish this
for hi5 -- iframes are cached at the browser and CDN level.
That said this leave out UserPref support, but I'm fine with that as a
tradeoff.
Perhaps we should focus on delivering the application as one cacheable
chunk and the per-user/preload data in a second chunk?
On Oct 3, 2008, at 9:35 AM, John Hjelmstad wrote:
Hi Ian:
You're right, it's the gadget XML parse prior to manipulation. It's
doing
DOM-based parsing, and I suspect you're right about the load of small
objects involved. At present I see that as a requirement, though, to
deal
with semi-well-formed input. We've talked about requiring XHTML or
something
close to it as a prerequisite for rewriting - which would make parsing
vastly easier and rather trivial to implement - but that's a spec
issue if
it's to be a general platform requirement.
--John
On Fri, Oct 3, 2008 at 12:53 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
I don't know the precise details of this conversation or exactly
which
parsing, CajaHtmlParser or XmlUtil.parse, you are talking about,
but if its
the Gadget XML parse prior to manipulation, and this is still using
DOM
based parsing, then its probably going to be slower than SAX under
load, and
vastly slower than Stax. The reason I say under load, is that DOM
parsers
tend emit lots of small objects which, once they get out of eden,
overload
the GC which will dominate as resources become scarce. Having said
that,
gadget parse trees probably don't exist long enough to get out of
eden.
Ignore me if you are talking about some other parsing going on within
gadgets.
Ian
On 3 Oct 2008, at 02:03, Kevin Brown wrote:
The real thing we should be investigating is why it takes 25ms to
use the
parser on buddypoke when it only takes 10ms to cajole it.
Paul Lindner
[EMAIL PROTECTED]
