SDM memory footprint

[Nicolas Morel]

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 ?

[Daniel Kurka]

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

--
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-co...@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.

--

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

[Nicolas Morel]

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> 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 ?

--
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+unsubscribe@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.

[Jens]

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.