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 <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
