Sherry,

What component (XML, BPEL/XSLT, Secure Web Services) of Enterprise Pack really 
need this option? We definitely can do this but we`d like to know the basis of 
such a change (we need to add to the the installer specs).
Is there another issue that causes this change?


Thanks,
Dmitry

It would be much more preferred if this change was done in the IDE build script, 
rather than in the installer.

The current setting of -J-Xms32m was deduced as the minimal initial heap size
needed for IDE startup without heap resizes. Heap resize is time-consuming
operation and we have to avoid it during startup. So slightly less than 32meg is
needed during the startup of NetBeans. On the other hand the heap size should
not be unnecessarily large right after startup.

Does enterprise pack really need 128meg of heap during its startup? For what reason?

Sherry,

Could you please update the issue? 

Thanks,
Dmitry

The IEP Module.  I am ccing Bing Lu for additional info.

Bing,

Do we really need this option?
What will occur if we don`t add this option?
What will occur if we add option -J-Xms64m instead of -J-Xms128m?

Please answer ASAP. We have just one day to resolve this issue.

Thanks,
Dmitry

The fix is ready to be committed. 
Waiting for Bing`s comments...

Fix committed? Doesn't seem there was an agreement regarding its necessity.
Changing global parameters affects the performance of the whole IDE. Please
provide a justification for this change.

Honza, fix is not committed yet. Waiting approval from Tonda and Pavel

Honza,
The fix WAS NOT committed yet. It exists only on my developer system and would 
be integrated only after:
1) the Bing`s explanation, why it is so important to add this option, appear
2) I get 'OK' from the performance team

Stay tuned. I have contacted Bing personally (together with his manager;) ) by 
e-mail and hope to get a quick response from him.

Ah, sorry. I misread "ready to be committed" as "already committed". Anyway, I
don't think anyone can approve this change until the justification is provided.

Dmitry

   No, I don't really need this option to run NB. But I feel NB is faster
with greater -J-Xms128m.  Everytime I change my etc\netbeans.conf file to
set -J-Xms128m after installing NB. This option is not as important as
changing -J-Xmx128m to -J-Xmx256m.  Java Editor's find-usages
run faster with -J-Xmx256m or greater. -J-Xms128m may not be a big deal.


What will occur if we don`t add this option?
What will occur if we add option -J-Xms64m instead of -J-Xms128m?

Please answer ASAP. We have just one day to resolve this issue.

Thanks,

Dmitry

   No, I don't really need this option to run NB. But I feel NB is faster
with greater -J-Xms128m.  Everytime I change my etc\netbeans.conf file to
set -J-Xms128m after installing NB. This option is not as important as
changing -J-Xmx128m to -J-Xmx256m.  Java Editor's find-usages
run faster with -J-Xmx256m or greater. -J-Xms128m may not be a big deal.


Thanks

Bing

blu, there have been a serious ongoing effort put into finding the optimal
memory configuration parameters over time. The values are not going to be
changed based on a "feel". Please provide results of specific measurements to
justify the requirement.

Also, this issue started as a request for increasing the initial memory heap
size (-Xms). Now, you're requesting that the max heap size (-Xmx) be increased.
Is that another requirement? Any justification for that except that "find
usages" seems to be running faster?

The only thing that -Xms128m can change (compared to -Xms32m) is a startup time
or first time to perform some memory intensive operation. On the other hand, it
immediately raise RSS of a process that might not need that much memory.
This is why nb-perf is against the change.

Note: we'd be for such a change (but not _that_ drastic) in case it would really
help reduce the startup time by eliminating heap resize during the startup.
This is easy to prove by measurements and by -J-verbose:gc

Based on discussion close as will not fix.