On Java and C++

[Phlip]

By the way, if i may add, i dont know who submitted the language
comparison articles for that wiki but it is littered with information that
simply is not true.

Use the Edit button and fix it.

 

[Remon van Vliet]

The problem is not with the performance of the graphics hardware. The
limiting factor is the initialization of the virtual machine.
Undoubtedly, if things got anywhere near the point of maxing out the
graphics card, an applet would greatly outperform Flash.

I know, but it's two different things, initialisation isnt in the way of
performance and vice versa. That said, i can see how VM initialisation is a
limiting factor. Having to wait 5+ seconds kind of shoots applets down as a
good option for dynamic web content.

 

[Remon van Vliet]

Use the Edit button and fix it.

Hehe, fair enough, but i dont really care either way, just figured i'd point
it out for those that use it as a reference.

 

[Luc The Perverse]

I know, but it's two different things, initialisation isnt in the way of
performance and vice versa. That said, i can see how VM initialisation is
a limiting factor. Having to wait 5+ seconds kind of shoots applets down
as a good option for dynamic web content.

I wonder if running the JVM as a process would eliminate this delay, or at
least greatly reduce it

 

[Andrew McDonagh]

longevity is usually solely related to the people that design the
application rather than the language it was developed in. That said, i think
he was simply making a point that writing commercial quality applications
using VB is tricky at best. I think that point is pretty valid.

cause it isn't - the company doesn't give a monkeys who wrote the thing
- just that it works or that the work arounds for any problems work. A
company doesn't change things lightly, nor just because some developer
says they can do a better job.

There needs to be a clear business benefit involved in changing - e.g.
the OS the app is running on is being upgraded and the new app wont work
on it (as is often the case with WindowsNT -> WindowsXP)

 

[I V]

Which is a problem because? You dont have to point out continuously that the
GC doesnt allow exact control over cleaning up discarded objects. We all
know that and consider that a good thing. What'd be more interesting is to
finally hear a valid reason why it's actually a problem rather than an
advantage.

The issue isn't memory. The issue is other resources which are in short
supply, or which may not get cleaned up automatically by the OS, or which
you need to ensure are cleaned up as quickly as possible - database
connections, perhaps, or shared resources in a windowing system, or
mutexes. In other words, things for which you would use the dispose
pattern in Java.

Don't think of RAII as a way to manage memory (it is used for that, but if
C++ had GC, RAII for memory management would be a lot less important),
think of it as a way of automating the dispose pattern.

 

[Oliver Wong]

Well it's worth noting that the VM initialisation is what's causing the
delay, and that only happens once. Actually loading and starting the
Applet (at least on my system) is a matter of a second or slight more.

I was a bit surprised at the 5 second figure I arrived at as well. This
was done basically by holding my wrist watch up to the screen, and taking
the "start time" to be when I saw the HTML rendered, and the "end time" to
be once I saw the applet/flash actually running. My watch only has 1 second
precision, and my reaction time as a human may have been a factor, but I
think I was accurate to within, say, 0.7 of a second.

AFAIK, I didn't have load any applets during that instance of FireFox. I
had Eclipse and jEdit running in the background, but I'd be surprised if
Firefox could somehow "share" the VM with them.

Oh yes? That surprises me, i've always assumed Flash to be faster if
you're going for the same graphical quality, especially where antialiasing
is involved. Interesting stuff..

I also assumed Flash would be faster for the graphics stuff. Flash has a
3D API too, doesn't it?

- Oliver

 

[Oliver Wong]

Here's your half penny...payment for services rendered...

Thanks. The future of ecommerce is all about micro payments.

Now if I could only average a billion transactions a day like this.

- Oliver

 

[Remon van Vliet]

The issue isn't memory. The issue is other resources which are in short
supply, or which may not get cleaned up automatically by the OS, or which
you need to ensure are cleaned up as quickly as possible - database
connections, perhaps, or shared resources in a windowing system, or
mutexes. In other words, things for which you would use the dispose
pattern in Java.

Don't think of RAII as a way to manage memory (it is used for that, but if
C++ had GC, RAII for memory management would be a lot less important),
think of it as a way of automating the dispose pattern.

I'll take your word for it, but his argument was that having exact control
over memory usage is somehow an advantage.

As for resources that are in short supply, i've never actually run into such
an issue with Java to begin with and i develop high concurrency servers.
Reusable resources are usually pooled and cleanly released when necessary,
and i cant really think of any other kind of resource that would cause
issues. In fact i cant even recall a single case of resource leak in my
entire Java career, and i dont exactly believe that's due to above average
skill, it simply comes with Java, or is avoided by using Java.

 

[Remon van Vliet]

I wonder if running the JVM as a process would eliminate this delay, or at
least greatly reduce it

I think it sort of is after the first invocation. I cant say for sure
though.

 

[Remon van Vliet]

cause it isn't - the company doesn't give a monkeys who wrote the thing -
just that it works or that the work arounds for any problems work. A
company doesn't change things lightly, nor just because some developer
says they can do a better job.

There needs to be a clear business benefit involved in changing - e.g. the
OS the app is running on is being upgraded and the new app wont work on it
(as is often the case with WindowsNT -> WindowsXP)

I think i may have had a bad choice of words there. I didnt mean the actual
people are at all relevant when it comes to longevity, but that skilled
people will come up with a design that helps longevity. A proper design is
easily extensible and maintainable, and thus adds longevity because the
changes you mention arent as big an investment compared to designs that
arent easily extended. A company's willingness to change/extend their
software depends on so many things it's hard to generalize, but it's fair to
say that if the payoff of a certain chance is considerably higher than the
investment than that company is likely to go forward with the change. And
the investment is considerably lower for applications that are built with
evolution in mind.

And none of that is related to VB sucking when it comes to all that

 

[Remon van Vliet]

I was a bit surprised at the 5 second figure I arrived at as well. This
was done basically by holding my wrist watch up to the screen, and taking
the "start time" to be when I saw the HTML rendered, and the "end time" to
be once I saw the applet/flash actually running. My watch only has 1
second precision, and my reaction time as a human may have been a factor,
but I think I was accurate to within, say, 0.7 of a second.

AFAIK, I didn't have load any applets during that instance of FireFox.
I had Eclipse and jEdit running in the background, but I'd be surprised if
Firefox could somehow "share" the VM with them.

Hm, maybe FireFox starts the VM on startup? I have no idea..

I also assumed Flash would be faster for the graphics stuff. Flash has
a 3D API too, doesn't it?

So does Java though...sort of (Java3D)

 

[Timo Stamm]

I also assumed Flash would be faster for the graphics stuff. Flash
has a 3D API too, doesn't it?

No, there is no 3D API

Antialising is a good point. I am not sure whether Applets can compete
at that.

But overall graphics performance is not as good as one might think from
seeing flash movies on the web. They mostly run at 12 FPS (default
setting) instead of 25-50 (what I would choose in an Applet).


Timo

 

[Noah Roberts]

*SNIP*


Which is a problem because? You dont have to point out continuously that the
GC doesnt allow exact control over cleaning up discarded objects. We all
know that and consider that a good thing. What'd be more interesting is to
finally hear a valid reason why it's actually a problem rather than an
advantage.


Why are you so stuck on wanting control over these kind of things? Are you
under the impression you do a better job at manually alloc/deallocing memory
and cleaning up objects than the latest generation Java GC will do? I'm
getting a bit tired of all these unsupported assumptions. Either come with
practical examples/facts or just agree to disagree.

You are comming in rather late and/or don't have the knowledge to
understand what I am talking about.

Look up what RAII is and what it is used for, or read this thread where
it is spoken of quite a bit.

Then you will understand what I am talking about above.

 

[Noah Roberts]

I'll take your word for it, but his argument was that having exact control
over memory usage is somehow an advantage.

Actually, my argument is pretty clearly that knowing exactly when an
object is destroyed is somehow an advantage. Direct control over when
it occurs or not, knowing when and being able to guarantee that
behavior is very adventageous.

 

[Luc The Perverse]

I think it sort of is after the first invocation. I cant say for sure
though.

Typically I am opposed to background services running - but if I could make
Java programs initial startup cost go away, I could sacrifice a few MB.

Does anyone know for sure? (To be honest, java programs interest me more
than applets.)

 

[Phlip]

Look up what RAII is and what it is used for, or read this thread where
it is spoken of quite a bit.

Or read the huge multi-thread conversation regarding GC, deterministic
destruction, and the general proposal to add a 'finally' keyword to C++
that ran for the last 2 months at .

"There's enough material there for an entire conference" --Fawlty Towers

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Oliver Wong
<[email protected]>
wrote

Windows XP with SP2, Pentium 4 1.8Ghz, 1024MB RAM, Firefox 1.5.0.2.

Java took 3 seconds, Flash took 5 seconds.

I think part of the problem may be the loading of the
jar files for the applet. Java initialization, after
all, is not perceptible in the browser proper, though
the 1.5 version does show a "load in progress" screen,
which is an improvement over a mostly blank gray screen
in earlier versions.

Does your figure include the jar file loading?

In any event, ArcTest might have taken for me 4 seconds to bring up
something, and 1 more second to show an arc.

The RollerMouse demo took 6 seconds to come up and maybe 2-3 seconds to
load.

I'm thinking Internet time variance, or maybe server issues.

 

[Oliver Wong]

[Removed comp.lang.c++ ]

Typically I am opposed to background services running - but if I could
make Java programs initial startup cost go away, I could sacrifice a few
MB.

Does anyone know for sure? (To be honest, java programs interest me more
than applets.)

I believe there are efforts in that direction. The main obstacle to
overcome, from what I heard, is making sure static variables and class
loaders behave as if every program were invoked within their own JVM.

- Oliver

 

[Oliver Wong]

[Removed comp.lang.c++]

In comp.lang.java.advocacy, Oliver Wong
<[email protected]>
wrote


I think part of the problem may be the loading of the
jar files for the applet. Java initialization, after
all, is not perceptible in the browser proper, though
the 1.5 version does show a "load in progress" screen,
which is an improvement over a mostly blank gray screen
in earlier versions.

Does your figure include the jar file loading?

Elsewhere, I posted my highly scientific measuring method:

<quote>
This
was done basically by holding my wrist watch up to the screen, and taking
the "start time" to be when I saw the HTML rendered, and the "end time" to
be once I saw the applet/flash actually running. My watch only has 1 second
precision, and my reaction time as a human may have been a factor, but I
think I was accurate to within, say, 0.7 of a second.
</quote>

by "actually running", I don't count seeing Sun's Java logo. I waited
until I actually saw the arc being drawn. Similarly, for the Flash, I kept
timing past the "loading..." screen, and stopped when I saw those buttons
beginning to slide into position.

- Oliver