Jon Skeet [C# MVP] wrote:
Alun Harford <de*****@alunharford.co.ukwrote:
<snip lots of bits>
>Gabriele wrote:
>>VS.NET (C#) against VS.NET (VB.NET) about easy of development of GUI
Development of GUI in VS/C# is trivial, whereas in Java it's very
painful. Personally I found my GUI development to take 1/10th of the
time when I switched from Java to C#.
But do all your forms resize nicely? I've found that (prior to WPF)
it's very easy to create a *bad* UI in .NET, but hard to create a
*good* one. Java's layout managers take a while to get used to, but end
up creating a better app.
While it's true that you can use the VS "designer" to produce some
really bad code, I'd say that's true of any programming tool.
(All my forms resize nicely - well at least all the ones that I allow to
be resized resize nicely)
Oh, and I believe the Java GUI designers have come on a lot in the last
year or so. I haven't used them myself.
The problem isn't the design tool. I think the .NET framework is
superior to AWT/Swing.
(That said, I've not done UI stuff in Java for about 18 months - because
I prefer C# :-) )
>Java and C# both execute pretty quickly - they're both JIT compiled
languages...
Which is faster depends on what you're doing.
For raw processing power, Java is superior (the C# compiler needs
serious work on optimization).
Most optimisation isn't done by either the C# or Java compilers. It's
done by the JITs.
The JIT compiler is a compiler :-). And ideally it should be able to do
basic optimization.
I preferred the earlier sentence: it really *does*
depend on what you're doing. If you're using virtual methods which have
never been overridden and can be inlined, Java will be a lot better. In
other cases, C# will be faster. That goes to raw execution as well as
graphic libraries.
Swing/AWT is much slower than .NET/Windows forms because it does much
more work... if you were to have 'identical' programs as Java bytecode
and MSIL, I'd be impressed if a program can be constructed to make the
MSIL one go faster.
As an example, I recently found that a particular method I'd written was
running slowly, and had to modify it (I'd rather not have to do the
optimizing compiler's job, particularly in simple cases).
It was a more complex than this, but not much:
//input is a 256x256 bitmap
public Bitmap CopyBitmap(Bitmap input)
{
Bitmap output = new Bitmap(256,256);
BitmapData inputData= input.LockBits(new Rectangle(0, 0, input.Width,
input.Height), ImageLockMode.ReadOnly, PixelFormat.Format32bppArgb);
BitmapData outputData = output.LockBits(new Rectangle(0, 0,
output.Width, output.Height), ImageLockMode.WriteOnly,
PixelFormat.Format32bppArgb);
unsafe
{
byte* inputPtr = inputData.Scan0;
byte* outputPtr = inputData.Scan0;
for(int i=0;i<256*256;i++)
{
for(int j=0;j<4;j++)
{
*outputPtr = *inputPtr;
}
}
}
input.UnlockBits(inputData);
ouput.UnlockBits(outputData);
return output;
}
Any decent optimizing compiler will take that code and copy the data
words at a time instead of bytes at a time. Even the silly little
compilers I wrote as an undergrad could cope with that task!
But not the .NET CLR :-(
Still, I love it really. I just wish somebody at Microsoft would give it
the care and attention (and expert in optimizing compilers) that it needs.
Alun Harford
