Lew said:
It said no such thing. What it actually said was that your NB 6.1 is up
to date.
Which implies that there is no NetBeans 6.5, or any other number higher
than 6.1.
I suppose you are technically correct that it did not explicitly *say*
that, but it is a strong implication. "6.1 is the latest version" makes
it very unlikely that there is a 6.5, since it is very uncommon (if it's
ever happened at all) for an older version of something to have a higher
number than a newer version.
He said "what are your times?" You haven't answered that question.
That's because I don't have an exact number. I'd have to shut down NB,
dig up a stopwatch, and start it up again, and I can't be bothered to do
that at the drop of a proverbial hat.
I DID give an estimate, however, despite your implication above that I
didn't.
It is NetBeans 6.5. No need to be snide about it.
I am not being snide about anything. I am simply pointing out that
whatever it is, it is NOT NetBeans 6.1 and consequently might behave
differently from NetBeans 6.1.
Regardless, I've been using NetBeans since well before 6.1 and do not
observe the behavior you describe with NB 6.1 either.
CPU and RAM? JVM?
Not "almost anything", since 6.5 is an evolution from 6.1
That statement is in direct contradiction with my copy of NB 6.1
self-reporting as being the most recent NetBeans, presumably based on
data it retrieved from the NB Web site that can reasonably be
characterized as having come from the proverbial horse's mouth.
Of course, it could be the case that your statement is correct and my
copy of NB 6.1 is in error (somehow failing to detect the existence of a
more up to date version), rather than the other way around.
Still, it could be that 6.5 lacks some bug that 6.1 had, except that
what you observe is not what everyone observes, so it is more likely
something specific to your setup.
The problem with that hypothesis being that my setup is "nothing to
write home about". There is nothing exceptional, weird, strange, or very
far from the norm about it.
Not observed here, that phenomenon. I've not seen that either with NB
6.1 on Linux or Windows.
That is very odd, in light of the above.
Actually, it's extremely unlikely that it misuses the EDT that way,
given the Java expertise involved in its development.
Then the behavior observed stems from another cause, unrelated to my
network's speed, as I suspected all along.
More likely it is something about swap in your OS or GC.
Doubtful, since I see the slow-when-start-page-displayed behavior even
when the system's memory in use is smaller than the total physical
memory available, and separately since it is not a transient state that
goes away after a short time (as it would when something was finished
being swapped in) but persists for as long as the start page is visible.
You haven't answered Mark Space's question about your OS
I most certainly have.
but I would also look into your swap space allocation
2GB; and irrelevant (see above)
the -Xmx paramater in your netbeans.conf
Haven't touched this file, so this should still be the default, and so
if this were the cause it would affect most copies of NB 6.1. Apparently
most copies are unaffected, which points to the problem being elsewhere.
and what other apps are running at the same time. Having less RAM than
Mark Space's configuration, you could be seeing a swap artifact.
When NB has been foregrounded and in use for an hour plus and the
system's total memory consumption at the time is only around 700MB out
of a physical 1024?
Like Mark Space, I observe slow startup times for NB generally, an
attribute it shares with Eclipse BTW, while it does its self-assembly
and project-scan things. I do not see the UI freeze after that.
The slow startup time is not a primary complaint of mine. But it makes
problems that force the user to restart NB to be onerous enough for this
reason that I think suggesting people just resign themselves to
occasionally restarting NB is "not good enough".
I would look into your netbeans.conf.
Why? It is not possible that I've munged this file, for the simple
reason that I've not edited it. (Indeed, didn't know it existed until
this post.) (I assume making some changes in NB's options dialogs might
indirectly alter that file, but those dialogs should trap any attempt to
enter unreasonable values, and I can't recall messing with anything to
do with its memory use or related behaviors.)
You might wish to allocate a wee bit more -Xmx to NB
I doubt it. When it was doing its CPU-saturating-hang thing I noticed
the process size was upwards of 200 megs. I infer that the -Xmx is 256M
or more, which "ought to be enough", at least for the time being.
and perhaps tweak the GC parameters.
I definitely didn't make any changes to these, so in particular didn't
make any that might have been ill-advised and that therefore ought to be
changed back.
Since my copy's GC parameters are still the factory defaults, if those
GC parameters were the problem, a large proportion of all NB 6.1
installs would be similarly affected, which you claim is not the case.