Debugging is terribly slow

[Magnus]

Hello,

I still have no solution for this problem. Running and debugging web applications from within eclipse ist very slow, so that one cannot really work on the project anymore.

Do others have this problem, too?

Magnus

[Boris Brudnoy]

Yes, the larger the application the more resources Development Mode consumes. I often rely on self-reviewing code and wind up compiling the application to test features. Unit testing is your friend as well, reducing reliance on the debugging functionality of Dev Mode. In one of my non-trivial GWT projects (10K LOC) I defer to debugging only when completely stuck. Finally I noticed that GWT apps run much faster in Dev Mode on Firefox then in Chrome. 

I'm placing high hopes on the upcoming Super Dev Mode alleviating the problem.

Boris     

[Joseph Lust]

Magnus,

It is likely not the response you're looking for, but our app has grown so large we faced the same issues as you. We're taking the radical step of breaking it into many standalone modules that can link between each other (compile to different wars). That way, when you're opening/debugging a module it still works in a few seconds, not minutes. It sounds like a big step, but makes many other things like partial upgrades and partial deployments possible as well. It also enforces decoupling of modules meaning our 45 devs don't step on each other as much. You might want to consider it.

Sincerely,

Joseph

[Magnus]

Hello,

thanks for this advice. I am thinking about it for some days now and I would like to give it a try.

Therefore, I searched for some documentation on this technique. But all that I found was the article "Organizing Project" in the GWT docs. In this article, the reason for using modules is described as follows:

"Typically, you create a new module when you want to package up a library of GWT code that you want to reuse in other GWT projects."

Well, this is not the case for me. So the whole article does not match my intention. What I need, is some tutorial that describes how to split my application into several modules. I just wonder where to cut the project into pieces.

Can you point me to some tutorial, please?

Thank you
Magnus

[Jens]

It is likely not the response you're looking for, but our app has grown so large we faced the same issues as you. We're taking the radical step of breaking it into many standalone modules that can link between each other (compile to different wars). That way, when you're opening/debugging a module it still works in a few seconds, not minutes. It sounds like a big step, but makes many other things like partial upgrades and partial deployments possible as well. It also enforces decoupling of modules meaning our 45 devs don't step on each other as much. You might want to consider it.

When you have multiple independent "mini" apps all with their own host html page, have you found a good solution how to avoid re-downloading the same code multiple times (GWT widgets/features, outer app shell with main menus)?

-- J.

[Joseph Lust]

Jens,

We've not yet solved redownloading those pieces. However, the overhead is worth it to us so that we can redeploy just a single module (entrypoint). 

Sincerely,

Joseph

[Thomas Broyer]

On Saturday, July 7, 2012 3:29:06 AM UTC+2, Joseph Lust wrote:

Jens,

We've not yet solved redownloading those pieces. However, the overhead is worth it to us so that we can redeploy just a single module (entrypoint).

As you said though, this is a "radical step", and you could have built "harnesses" to speed-up debugging without changing the final output; just like –as I've already said it here and there– Wave has a specific module with a specific EntryPoint that loads only the rich-text editor, and another one for the threaded UI: using only part of your components ("screens", "widgets", etc.) can greatly speed-up DevMode, and you can make specific tools to help you in debugging (the rich-text editor harness of Wave let you generate operation-transforms from a pair of text boxes and see their results in the document, and shows how the document is represented as a "wavelet" –that it correctly detects where your cursor is, what the current selection is, etc. all the things that will be sent to the server so others will see your caret moving on their screen; the thing we now have in Docs for a year or two).

In Wave, this was an "horizontal split", but in an "enterprise" app you could probably split "vertically" (the "admin" screens, etc.) Overall, the smaller the "source path" (and if you can, the classpath too), the faster the DevMode.

[Magnus]

Well, my application is a chess server. The first thing I could identify as a separate module is the "game" area, where you see the chess board and where you can make moves and that. Second there is a "chat" area, where users can send messages to others. Then, there are the profile settings for each user, and so on...

Are these the parts that could be separate modules?

Do these only affect the GUI/client part?

Again: Is there a tutorial somewhere?

Thanks
Magnus

[Jens]

Well, my application is a chess server. The first thing I could identify as a separate module is the "game" area, where you see the chess board and where you can make moves and that. Second there is a "chat" area, where users can send messages to others. Then, there are the profile settings for each user, and so on...

Are these the parts that could be separate modules?

Seems like. I would start by creating modules for different screens though and not for different components on the same screen. Splitting out components can still be done if a "screen" is still too slow.

Do these only affect the GUI/client part?

Yes.

Again: Is there a tutorial somewhere?

I am not aware of any but its not that hard I guess. Following your information you could create:

- GameArea.gwt.xml

- DevGameArea.gwt.xml

- Chat.gwt.xml

- DevChat.gwt.xml

Your current App.gwt.xml will inherit GameArea.gwt.xml and Chat.gwt.xml and should still work. The Dev*.gwt.xml files would inherit their non-dev versions and provide a new EntryPoint class. This EntryPoint class is then responsible to initialize your GameArea and display it in the RootPanel. That way you could start DevGameArea.gwt.xml in Dev-Mode and only see the game area widget. 

In DevGameArea.gwt.xml and DevChat.gwt.xml you would add a "rename-to" attribute that has the same value as your main App.gwt.xml. That way you don't need additional host html pages for your smaller modules.

But honestly a Chess game does not sound that large, so maybe you have a different problem that causes slow debugging. All I can say is that I can debug an application with about 120 KLOC client code without splitting it into several smaller modules. When a breakpoint is reached I can step through the code without any problems. But having smaller modules is also nice for SuperDevMode in GWT 2.5. Smaller modules should make the compilation super fast.

Nevertheless I would like to play a game against you in your chess GWT app! ;-)

-- J.

[Joseph Lust]

Yes, pretty much what Jens said. You could compile your application a a number of different modules, and then launch and test various entry points to modules as needed to simplify testing. So, for example, the chess engine or chat module could be separate projects inherited by your main project.

Curious though, what chess rules engine are you using? I was wondering if it was a big heap of Java you're compiling to JS, in which case it may be the culprit of your slowness.

Sincerely,

Joseph

[Shawn Brown]

> Do others have this problem, too?

No I didn't at all, and then suddenly I did. Virtually unusable.

The difference was I upgraded to EE IDE for Web Developers and the
validation it does really messed me up.

I turned everything off except for the xml, jsp, html and web validators.

Now it's back to normal. Not sure what the issue was but there sure was one.

[Magnus]

Am Sonntag, 8. Juli 2012 00:40:59 UTC+2 schrieb Jens:

I am not aware of any but its not that hard I guess. Following your information you could create:

- GameArea.gwt.xml

- DevGameArea.gwt.xml

- Chat.gwt.xml

- DevChat.gwt.xml

What's the idea behind having two modules for each area (non-dev and dev)?

Magnus

[Magnus]

Sounds interesting!

Where in eclipse are these settings?

Magnus

[Magnus]

Curious though, what chess rules engine are you using? I was wondering if it was a big heap of Java you're compiling to JS, in which case it may be the culprit of your slowness.

I am not sure what you mean with rules engine. The validation of moves is done on the server side. It does not seem to have something to do with it, because debugging is always slow, not only when making moves.

Magnus

[Jens]

What's the idea behind having two modules for each area (non-dev and dev)?

The dev version contains an <entry-point> declaration that can start and show your smaller part of the app as described in my original post. So GameArea acts als library and DevGameArea is a small app that shows you the GameArea only. During compilation of your main app the compiler does not see the additional entry points if you put them into separate dev modules. Well and in general you most likely want to user different log levels / specific user agents during development anyways so a dev module is always a good idea (you don't have to change the production module).

In my apps I always have:

App.gwt.xml (production configuration)

DevApp.gwt.xml (inherits App.gwt.xml and sets development configurations like log levels)

DevAppSafari.gwt.xml (inherits DevApp.gwt.xml and defines safari as single user.agent)

In all three modules I have "rename-to=app" so I only need a single host html page that includes app.nocache.js.

-- J.

[Magnus]

Nevertheless I would like to play a game against you in your chess GWT app! ;-)

Please send an email address and a nickname to ch...@muenchen-mail.de and I'll create an account :-)

Magnus