[Laszlo-dev] Fwd: [JIRA] Commented: (LPP-6017) file size of compiled swf applications has gotten significantly larger

[Henry Minsky]

---------- Forwarded message ----------
From: Henry Minsky <hminsky at laszlosystems.com>
Date: Mon, Jun 2, 2008 at 5:52 PM
Subject: Re: [JIRA] Commented: (LPP-6017) file size of compiled swf
applications has gotten significantly larger
To: "P T Withington (JIRA)" <jira at laszlosystems.com>


I suppose a compromise might be to emit the instance classes in swf8/dhtml
in debug mode ...
might be too confusing for people though...



On Mon, Jun 2, 2008 at 4:50 PM, P T Withington (JIRA) <
jira at laszlosystems.com> wrote:

>
>    [
> http://www.openlaszlo.org/jira/browse/LPP-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43854#action_43854]
>
> P T Withington commented on LPP-6017:
> -------------------------------------
>
> The big culprit is 'instance classes':
>
> We remodularized the tag compiler so that when an instance has a method
> (which also means if it has any contstrained attributes or handlers), we
> emit an anonymous class.  We have to do this for swf9/JS2 so that those
> methods are proper methods.  [Proper methods means that 'implicit this' and
> 'super' use the JS2 class mechanism, rather than our emulation of it, which
> is what happens in JS1 runtimes.]
>
> When we did this, I did it for all run times, because I wanted the maximum
> exposure to incidental testing.  This did shake out a lot of bugs with the
> 'instance classes' mechanism; but, it is also responsible for a lot of code
> expansion.  Despite my claim above, there is a certain amount of class
> declaration 'boilerplate' that we have to emit now, and it just plain mounts
> up.  Especially with components, which tend to have many, many nested view
> instances that are constrained to each other.
>
> I could just turn this mechanism off for JS1 runtimes -- they will continue
> to work in the old-fashioned way, but I worry about the risk of reduced test
> coverage.
>
> Opinions?
>
> > file size of compiled swf applications has gotten significantly larger
> > ----------------------------------------------------------------------
> >
> >                 Key: LPP-6017
> >                 URL: http://www.openlaszlo.org/jira/browse/LPP-6017
> >             Project: OpenLaszlo
> >          Issue Type: Bug
> >          Components: Compiler
> >    Affects Versions: RingDing (4.1)
> >            Reporter: Henry Minsky
> >            Assignee: P T Withington
> >            Priority: P0
> >             Fix For: RingDing (4.1)
> >
> >
> > for examples/components/style_example.lzx
> > comparing trunk with the release "pagan deities" (which I happened to
> have built)
> > trunk: 233560
> > pagan: 188232
> > I did a simple experiment in my emacs buffer taking the output of
>  running lzc --script, and then trying to
> > gzip compress that javascript code.
> > When I replaced the long method and class names with simple integers, the
> gzipped size went down
> > quite a lot. That leads me to think that the gzip compression being used
> in our swf code generator is
> > not really able to do a good job of compressing the new method/class
> names that we generate.
> > It's also possible that we're not making optimal use of the constants
> table, or are overflowing it quickly (it's only
> > 64K I thought, per code block tag or something?)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://www.openlaszlo.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com




-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080602/09840065/attachment.html