Skip to main content

GUI performance and gernerated code

17 replies [Last post]
Anonymous

I recently used NetBeans / SunONE Studio for designing some complex Frames. It worked, but I kept reading in newsgroups that the generated code is too complex and too slow compared with handmade code.

Is that true? Where is the code generation lousy, where is it better to just code it?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Anonymous

> I wanted to point at the way this is solved in
> UICompiler (and QtDesigner) by having a grand total
> of 3 layouters. A horizontal, vertical and grid
> layout.
> While not limiting functionality this means that the
> graphics designer can use that application and create
> good code via point and click.

I tried the UICompiler. Greate news the the QT stuff gone GPL on MacOS ;)

It took a while to make it work on OS X, but after some problems it's pretty easy now. :)

Anonymous

> Generally speaking the generated code could very well
> be slower. This has mainly to do with bad chosen
> layouters and other stuff that require knowledge of
> Swing that a 'UI designer' obviously lacks.

Well my prolem is that the UI designer has more experience as I have ;) What do you mean with bad chosen layouters? When I design something with the GUI editor lets take a Frame as example. On that Frame I place a panel layouted with BorderLayout or so and add buttons, textareas, then another panel with GridBagLayout whatever. It's not the designer that chooses the layout, it's me. And when I take the wrong decissions with the desinger, I'd do the same be hand.

> That said I have been around that bend a lot of times
> and wrote a layouter that makes my life easy; and the
> UICompiler project (Free) is generating code that
> uses just one layouter and has very good 2-step
> compiling that make it fast as well as short.

Ok, that makes sence.

> Oh, and no 'DONT EDIT' blocks here; we generate java
> code every time you save your GUI file again in a MVC
> way.. Just read the project pages at http://uic.sf.net

thanks

zander
Offline
Joined: 2003-06-13

> > Generally speaking the generated code could very
> well
> > be slower. This has mainly to do with bad chosen
> > layouters and other stuff that require knowledge
> of
> > Swing that a 'UI designer' obviously lacks.
>
> Well my prolem is that the UI designer has more
> experience as I have ;)

With the 'UI Designer' i meant a person like a graphics designer that creates the UI in your point-and-click application.
(s)he obviosly has less experience in Swing programming then you do :)

> What do you mean with bad
> chosen layouters? When I design something with the
> GUI editor lets take a Frame as example. On that
> Frame I place a panel layouted with BorderLayout or
> so and add buttons, textareas, then another panel
> with GridBagLayout whatever.

Right; and many people use just one layouter in applications like JBuilder since they 'know' that layouter.
Its easier to create a correct GUI using the GridBagLayout since you allready know that then to think about using the Border layout.
Even while the latter is faster and less memory hungry.

I wanted to point at the way this is solved in UICompiler (and QtDesigner) by having a grand total of 3 layouters. A horizontal, vertical and grid layout.
While not limiting functionality this means that the graphics designer can use that application and create good code via point and click.

Anonymous

I am the original author of the Form Editor in NetBeans, and I guess I can shed a bit of light on what my design centers were about 5 years ago when I created its first version (actually, it was a second generation, after a Form builder in a project called Xelfi, that utilized its own, pre-JavaBeans component architecture).

The major design principles were:
- the code generated needs to be very clean, and as close as possible to what I would write by hand
- the code generated must be all standard Java, no proprietary runtimes
- the code must perform well
- the code that is regenerated (i.e. modified by the tool) must be clearly separated from the code that the programmer writes by hand (I will come back to this in the second part of this mail)

First on the topic of generated code performance.

The generated code performance if affected in 3 primary ways:
1. is the layout/components initialization code optimized for performance?
2. is the GUI building functionalities rich enough to avoid deep nesting of containers with different layout managers?
3. the event handling code performance

For NetBeans we are doing 1. and 2. quite well, the layout building and components initialization is straighforward (i.e. simple sequence of steps that cannot be further significantly optimized) and for implementing the layout you are generally OK with using one container with GridBagLayout, as there are several ways to help you do that (conversion of Absolute positioning to GridBag, visual GridBag designer).
In terms of 3. we are actually not generating the most performance optimized code, as currently each Event type uses anonymous innerclass to process the events. There are better ways to code this in terms of performance (like making the form class itself implement the interfaces, or override the processEvent method), but all of them generate code that is very hard to read.

In general, we never observed that the generated code performance would be problematic, as GUI typically is not the problematic sweet spot with performance, unless you are doing something really silly.

------------

On the topic of being able to modify the generated code by hand, which is usually referred to as two-way editing. My philosophy always was to allow the user to do everything thathe needs to do, but do it in a way that is safe and fast.
For me, protecting the code that gets regenerated always was a conscious decision rather than a shortcut, as I believe that it is impossible to get the user intent completely right, and the danger of (silently!) losing some pieces of code semantics are high. So my decision was to protect the generated code, and rather provide ways how the developer can insert pieces of code at all places he needs to, that would ensure that 99% of what he needs to do he can.

Anonymous

> In general, we never observed that the generated code
> performance would be problematic, as GUI typically is
> not the problematic sweet spot with performance,
> unless you are doing something really silly.

Ian, thanks for your post. I was just wondering, because the generated code is not very different from the code I would write by hand and as I could see in some examples from SUN. But hearing other people say that the code is too bulky and slow it made me think what can be wrong there. Good to hear some "official" opinion from someone who has irst hand experiences.

hpl
Offline
Joined: 2003-06-29

Why generate Java code to describe a GUI ?

The code is for speaking to the user and to request resources like a database.
The SWING GUI is well defined by properties and his hierachical order.
A Frame with a menubar and a panel in the center. Here a toolbar in the North and another panel in the center, here a tabbedpane with panels, a.s.o.
The LayoutManagers are doing the job to place it on the screen.
Your job is to define each component and their relationsship to others. This can be done in XML outside your code.
At runtime the XML is to parse, all components are to build and putting together.
The only thing that you have to get are the events.

This idea works even with complex GUIs and it is fast.
Have a look at http://www.jeasy.de and see the hardcopies.
Start the Example as an applet and see the peformance.
It is really no line of javacode to build the hole GUI at startup.

Thanks to the SWING team for a clean implementation. To do the same on .NET is more tricky.

Anonymous

But what are with components that are note standard in Swing? Take for example you are making an ICQ client and you found a nice Swing based component to display your buddy list. Can I use JEasy / JBeaver / UICompiler to plug in other components. I tried it with UICompiler but it diesn't work so far :(

srotman
Offline
Joined: 2003-06-16

> I tried it with UICompiler but it doesn't work so far :(

If you experience trouble with the UICompiler you can tell us about what you tried and what went wrong (preferably by sending an e-mail to uic-user@lists.sourceforge.net); that way we can improve the product (and also our documentation, guidelines, faq. etc.)

hpl
Offline
Joined: 2003-06-29

Why generate Java code to describe a GUI ?

The code is for speaking to the user and to request resources like a database.
The SWING GUI is well defined by properties and his hierachical order.
A Frame with a menubar and a panel in the center. Here a toolbar in the North and another panel in the center, here a tabbedpane with panels, a.s.o.
The LayoutManagers are doing the job to place it on the screen.
Your job is to define each component and their relationsship to others. This can be done in XML outside your code.
At runtime the XML is to parse, all components are to build and putting together.
The only thing that you have to get are the events.

This idea works even with complex GUIs and it is fast.
Have a look at http://www.jeasy.de and see the hardcopies.
Start the Example as an applet and see the peformance.
It is really no line of javacode to build the hole GUI at startup.

Thanks to the SWING team for a clean implementation. To do the same on .NET is more tricky.

zander
Offline
Joined: 2003-06-13

Generally speaking the generated code could very well be slower. This has mainly to do with bad chosen layouters and other stuff that require knowledge of Swing that a 'UI designer' obviously lacks.

That said I have been around that bend a lot of times and wrote a layouter that makes my life easy; and the UICompiler project (Free) is generating code that uses just one layouter and has very good 2-step compiling that make it fast as well as short.

Oh, and no 'DONT EDIT' blocks here; we generate java code every time you save your GUI file again in a MVC way.. Just read the project pages at http://uic.sf.net

janunezc
Offline
Joined: 2003-06-11

Just a question... what is MVC?

jeff
Offline
Joined: 2003-06-10

MVC: Model View Controller

See [url=http://java.sun.com/products/jfc/tsc/articles/architecture/index.html]here[/url] for a bit of the history/architecture of Swing.

augusto
Offline
Joined: 2003-06-11

> Is that true? Where is the code generation lousy,
> where is it better to just code it?

Yes, that can be true. I don't like auto generated code, because our codebase has changed dev tools many times, and i don't like to be locked in a particular IDE. I specially don't like block comments of the "DONT MODIFY THIS CODE AT ALL" type.

If you hand code, you can optimize the UI, because you know exactly how you want to handle things.

But, for simple forms and interfaces, a UI builder is not a bad idea. If you want a simple form to enter name, and simple info, performance is not an issue. If are more productive, use the tool then.

So to me the general idea is, if you have simple stuff to do (and simple is subjective) go ahead and use the builder. For more complicated and dynamic architectures, hand coding might be your best bet. And if you're not confortable with hand coding the UI, just use the builder and don't worry about performance. You can always optimize later once you have everything functional.

janunezc
Offline
Joined: 2003-06-11

>I recently used NetBeans / SunONE Studio for designing some complex Frames. It worked, but I kept reading in newsgroups that the generated code is too complex and too slow compared with handmade code.

Have you tried NetBeans 3.5, It is really fast, and promises to be truly faster (the fastest ever) when used with JDK 1.4.2 from SUN which is actually in BETA.

If you are going to try, use the zip/tar version of the distribution. The installer failed on my Windows 2000 Pro. Station but the zip worked very fine and a lot faster than previous versions.

I saw Previous versions of NetBeans VERY slow, almost un-usable but this 3.5 is really goood.

See U.

Anonymous

Thanks for your reply, the NetBeans perofrmance is not the probem. I am using it on my G4 with JDK 1.4.1 and it is OK.

I was wondering about the generated code from the GUI designer. If I look at that code, I wouldn't make it very different when I would make it by hand without an IDE.

Can the generated code be optimized by hand? I don't mean some little things, I read in newsgroups about really big improvements?!?

Thanks,

Patrick

janunezc
Offline
Joined: 2003-06-11

I am not an expert on the matter, but I will share some "opinions" on it.

First a question: What is G4?

Second, I think the code generated by NetBeans is "protected" because it is modified by the IDE every time you do something in the graphical envirnoment from even move a control from its position to setting a property.

I think, one way would be, once you have your application ready to ship, open the .java files with an editor other than the NB IDE, and then make the modifications by hand... It may sounds like a long path but you would have full control of it.

I plan to research a little bit on this during the following weeks, to see what the effect is to hand-modify a .java file generated by the IDE.

I saw that there is a .form file that seems to be "binary" that surely controls the forms specifics allowing the graphical interfacing without including protection clauses on the .java file of the form.

I also saw a .nbattrs file but it does not seem to be directly related to the forms but may be to the projects...

Interesting topic... may be we can learn something here...

Regards,

JN

Anonymous

Oh, the "G4" is a shortcut for an Apple PowerMac with a PowerPC processor. Like this: http://www.apple.com/powermac/