Re: MVP framework(s) doubt

Sorry about the delay :)

The main issue that I am having is in Eclipse, something when I make a
change (little change) and I reload my app in Firefox I get this on
the console:

java.lang.OutOfMemoryError: PermGen space
[ERROR] Out of memory; to increase the amount of memory, use the -
Xmx flag at startup (java -Xmx128M ...)

So that's why I believed that cutting the number of classes could
solve my problem.

BTW i am on MacBookPro i5 with 4MB, using Eclipse Helios 64 bit.

On Nov 26, 2:31 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> What are your perf issues? Are they in DevMode or production mode? If you
> don't have perf issues in prod mode, then you don't have a perf issue:
> DevMode *is* slower; and moreover code splitting won't help.
> It's also important to define *which* are your perf issues: if it's
> download time, then code splitting can help, if it's about "runtime"
> performance, then it won't, and you'll have to find the bottleneck.
> Having a lot of classes can be the problem, but I highly doubt it is.
> We do have thousands of classes, and we use RequestFactory and the Editor
> framework, which generate a whole lot more, and we haven't had any negative
> feedback (yet) about performance.
>
> If you want to reduce the number of files you have, then you can cut the
> number of places by using, say an EditPlace with a field telling which kind
> of "entity" is being edited, of a FooPlace with a field telling which
> "action" is being done on the Foo entity (edit, list, etc.) But I doubt
> it'll change much things about performance (and unless you measure it and
> determine it's your bottleneck, it's not worth trying to "fix" it).
>
> So, first, if you have a perf issue, measure and determine where it comes
> from (you can use SpeedTracer in Chrome, or any browser's profiling tool;
> possibly after compiling in -style PRETTY so the code is readable, even if
> less optimized; you can also use the Duration class and some logging, using
> GWT.log() in DevMode or java.util.logging), then fix it. But without
> *knowing* (not only guessing, knowing!) what your perf issue is, it's
> likely you won't fix it just by trying a few things (and you could even
> make it worth, if you guessed wrong).
>
> Also, keep in mind that any framework that "cuts boilerplate down" uses
> code generation, so you might have fewer classes in your code, it doesn't
> mean there'll be less in the end (only the compileReport will tell you).
>
> Generally, bottlenecks are: DOM manipulations (misuse or overuse of
> widgets; switch to HTMLPanel and CSS for layout if possible, use Cell
> widgets for lists/tables/trees), and RPC (GWT-RPC or RequestFactory, or
> whatever; serialization is generally the culprit); and of course
> server-side code (database, etc.)

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.