[gwt-contrib] SDM memory footprint
Hi, I'm currently trying to migrate a big project at work from GWT 2.5.1 to 2.7.0 to test the new SDM. Even if the recompile took 1-2 min on 2.5.1, the SDM was working with -Xmx 1200m. It is already a lot of memory but was manageable. Now with 2.7.0-rc1, I have to increase it to -Xmx 1800m to avoid an OOM. Besides some bugs (https://github.com/ArcBees/GWTP/issues/614 or https://code.google.com/p/google-web-toolkit/issues/detail?id=4479), the incremental recompilation without modification works but it is still slow (~ 30 sec). The memory needed is too much for my machine, I keep swapping to a very slow disk :( And since we all have the same crappy laptop at work, the problem will be present for everyone working on this project. I guess the bump in memory is needed for the incremental compile to work correctly but what are the best ways to reduce it ? The project is not modular with a clean separation between client and server. So the SDM has all the libraries of the server in the classpath. If we split the client from server and reduce the classpath, can we expect a decrease in memory usage ? Or classes not used by the GWT module have no impact ? One of our RPC services uses Serializable so it generates a lot of code. Can it have an impact on memory usage too ? If that doesn't work, our only solution left is to divide in multiple GWT module and make something like turducken http://fr.slideshare.net/RobertKeane1/turducken-divide-and-conquer-large-gwt-apps-with-multiple-teams ? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4224704c-fc8c-493c-8f7a-b8c93357503e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SDM memory footprint
Hi Nicolas, Having no-op recompiles taking ~30s is very uncommon, even on our large projects this never exceeds 1s. Right now there is not much you can do to trim down memory usage for SDM. It really needs this amount of memory. Also keep in mind that SDM slows down a lot if it comes close to the memory limit. Some internal apps saw huge speed improvements for doubling their RAM used. The easiest solution on your part is getting more memory for your machines, since all engineering (like splitting up into multiple modules) comes with extra complexity (we do not handle recompile on reload for multiple modules right now if I am correct). We will eventually work on memory consumption, since some internal apps need up to 10 GB to work in SDM, but this work is not high priority and will unlikely land any time soon. I would strongly recommend getting more physical memory otherwise you will not have a productive working environment. -Daniel On Sun, Nov 16, 2014 at 11:23 AM, Nicolas Morel nmr.mo...@gmail.com wrote: Hi, I'm currently trying to migrate a big project at work from GWT 2.5.1 to 2.7.0 to test the new SDM. Even if the recompile took 1-2 min on 2.5.1, the SDM was working with -Xmx 1200m. It is already a lot of memory but was manageable. Now with 2.7.0-rc1, I have to increase it to -Xmx 1800m to avoid an OOM. Besides some bugs (https://github.com/ArcBees/GWTP/issues/614 or https://code.google.com/p/google-web-toolkit/issues/detail?id=4479), the incremental recompilation without modification works but it is still slow (~ 30 sec). The memory needed is too much for my machine, I keep swapping to a very slow disk :( And since we all have the same crappy laptop at work, the problem will be present for everyone working on this project. I guess the bump in memory is needed for the incremental compile to work correctly but what are the best ways to reduce it ? The project is not modular with a clean separation between client and server. So the SDM has all the libraries of the server in the classpath. If we split the client from server and reduce the classpath, can we expect a decrease in memory usage ? Or classes not used by the GWT module have no impact ? One of our RPC services uses Serializable so it generates a lot of code. Can it have an impact on memory usage too ? If that doesn't work, our only solution left is to divide in multiple GWT module and make something like turducken http://fr.slideshare.net/RobertKeane1/turducken-divide-and-conquer-large-gwt-apps-with-multiple-teams ? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4224704c-fc8c-493c-8f7a-b8c93357503e%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/4224704c-fc8c-493c-8f7a-b8c93357503e%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujipJhY8q1SNrL5%2BYB-2JLv9wWnTBe_jABgYDxofxkw2iVA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SDM memory footprint
Thanks for your answer Daniel. I'll try to convince my boss to buy us more physical memory but I don't have much hope :( Le dimanche 16 novembre 2014 13:15:29 UTC+1, Daniel Kurka a écrit : Hi Nicolas, Having no-op recompiles taking ~30s is very uncommon, even on our large projects this never exceeds 1s. Right now there is not much you can do to trim down memory usage for SDM. It really needs this amount of memory. Also keep in mind that SDM slows down a lot if it comes close to the memory limit. Some internal apps saw huge speed improvements for doubling their RAM used. The easiest solution on your part is getting more memory for your machines, since all engineering (like splitting up into multiple modules) comes with extra complexity (we do not handle recompile on reload for multiple modules right now if I am correct). We will eventually work on memory consumption, since some internal apps need up to 10 GB to work in SDM, but this work is not high priority and will unlikely land any time soon. I would strongly recommend getting more physical memory otherwise you will not have a productive working environment. -Daniel On Sun, Nov 16, 2014 at 11:23 AM, Nicolas Morel nmr@gmail.com javascript: wrote: Hi, I'm currently trying to migrate a big project at work from GWT 2.5.1 to 2.7.0 to test the new SDM. Even if the recompile took 1-2 min on 2.5.1, the SDM was working with -Xmx 1200m. It is already a lot of memory but was manageable. Now with 2.7.0-rc1, I have to increase it to -Xmx 1800m to avoid an OOM. Besides some bugs (https://github.com/ArcBees/GWTP/issues/614 or https://code.google.com/p/google-web-toolkit/issues/detail?id=4479), the incremental recompilation without modification works but it is still slow (~ 30 sec). The memory needed is too much for my machine, I keep swapping to a very slow disk :( And since we all have the same crappy laptop at work, the problem will be present for everyone working on this project. I guess the bump in memory is needed for the incremental compile to work correctly but what are the best ways to reduce it ? The project is not modular with a clean separation between client and server. So the SDM has all the libraries of the server in the classpath. If we split the client from server and reduce the classpath, can we expect a decrease in memory usage ? Or classes not used by the GWT module have no impact ? One of our RPC services uses Serializable so it generates a lot of code. Can it have an impact on memory usage too ? If that doesn't work, our only solution left is to divide in multiple GWT module and make something like turducken http://fr.slideshare.net/RobertKeane1/turducken-divide-and-conquer-large-gwt-apps-with-multiple-teams ? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4224704c-fc8c-493c-8f7a-b8c93357503e%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/4224704c-fc8c-493c-8f7a-b8c93357503e%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e182442f-3540-4124-bd2b-8a4b43d628e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] SDM memory footprint
I'll try to convince my boss to buy us more physical memory but I don't have much hope :( Just tell him the longer you wait for your laptop to get things done the more he is paying you for doing nothing but waiting. Then he should compare that with the cost of an adequate working machine with good CPU and enough memory (16gb min). Software companies giving their employees crap machines literally throw money out of the window for nothing. -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/560973d2-23e8-49d6-920b-38e14834874f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] SDM + gin + generated GinModule not working well together
Hi, I'm currently testing GWT 2.7.0-rc1 and one of my project using GWTP Rest-Dispatch https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch is not working under SDM. The compilation fails with this error : [ERROR] Unable to load gin module type [com.gwtplatform.dispatch.rest.client.RestGinModule], maybe you haven't compiled your client java sources? java.lang.ClassNotFoundException: com$gwtplatform$dispatch$rest$client$RestGinModule at com.google.gwt.inject.rebind.GinBridgeClassLoader.findClass(GinBridgeClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at com.google.gwt.inject.rebind.GinBridgeClassLoader.loadClass(GinBridgeClassLoader.java:108) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:340) at com.google.gwt.inject.rebind.GinjectorGenerator.loadClass(GinjectorGenerator.java:223) at com.google.gwt.inject.rebind.GinjectorGenerator.getPropertyModuleClasses(GinjectorGenerator.java:137) at com.google.gwt.inject.rebind.GinjectorGenerator.getModuleClasses(GinjectorGenerator.java:116) at com.google.gwt.inject.rebind.GinjectorGenerator.generate(GinjectorGenerator.java:72) at com.google.gwt.core.ext.IncrementalGenerator.generateNonIncrementally(IncrementalGenerator.java:40) The full stack trace is available in attachment. The problem has been reported to the GWTP team here https://github.com/ArcBees/GWTP/issues/614. The normal compilation works but not the incremental compile from SDM. I made a simple example available here https://github.com/nmorel/hello-gwt-rest-dispatch. From what I saw, the RestGinModule that gin is trying to load is generated by a GWT generator (VelocityGenerator https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-dispatch-rest/src/main/java/com/gwtplatform/dispatch/rest/rebind/VelocityGenerator.java .generateRestGinModule()) and passed to gin through the property gin.ginjector.modules. It seems unconventional but was working before. Any ideas what is going on please ? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e2edc888-db98-4d5d-b861-46f191523bd4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. GET /recompile/hello Job com.github.nmorel.hello.gwtp.HelloGWTP_1_0 starting job: com.github.nmorel.hello.gwtp.HelloGWTP_1_0 binding: user.agent=safari Compiling module com.github.nmorel.hello.gwtp.HelloGWTP Computing all possible rebind results for 'com.github.nmorel.hello.gwtp.client.HelloGinjector' Rebinding com.github.nmorel.hello.gwtp.client.HelloGinjector Invoking generator com.google.gwt.inject.rebind.GinjectorGenerator [ERROR] Unable to load gin module type [com.gwtplatform.dispatch.rest.client.RestGinModule], maybe you haven't compiled your client java sources? java.lang.ClassNotFoundException: com$gwtplatform$dispatch$rest$client$RestGinModule at com.google.gwt.inject.rebind.GinBridgeClassLoader.findClass(GinBridgeClassLoader.java:150) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at com.google.gwt.inject.rebind.GinBridgeClassLoader.loadClass(GinBridgeClassLoader.java:108) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:340) at com.google.gwt.inject.rebind.GinjectorGenerator.loadClass(GinjectorGenerator.java:223) at com.google.gwt.inject.rebind.GinjectorGenerator.getPropertyModuleClasses(GinjectorGenerator.java:137) at com.google.gwt.inject.rebind.GinjectorGenerator.getModuleClasses(GinjectorGenerator.java:116) at com.google.gwt.inject.rebind.GinjectorGenerator.generate(GinjectorGenerator.java:72) at com.google.gwt.core.ext.IncrementalGenerator.generateNonIncrementally(IncrementalGenerator.java:40) at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:760) at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:160) at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:79) at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:276) at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:265) at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:87) at
