Patch: Speed up NetBeans IDE execution

Jaroslav Tulach jaroslav.tulach at gmail.com
Wed Mar 11 18:08:49 UTC 2015


It might be better to leave the choice in hands on the person that does the
build. E.g. have two menu items in project pop-up menu to "Build" and
"Build with Dependencies" (I am trying to find out if that is possible). Or
do something different on "Build" vs. "Clean and Build" (I know how to do
it). Or leave "Clean and Build" action fast. But "Clean" followed by
"Build" do the complete build with dependencies (I know how to do it as
well).

Choosing the dependency-build style when invoking mx.sh seems to global and
too early too me.
-jt


2015-03-11 12:53 GMT+01:00 Doug Simon <doug.simon at oracle.com>:

> Hi Jaroslav,
>
> > On Mar 11, 2015, at 11:52 AM, Jaroslav Tulach <jaroslav.tulach at gmail.com>
> wrote:
> >
> > Hi.
> > I am using Graal with NetBeans and found various operations (rebuild of a
> > single module, execution) too slow. I believe the reason is that
> NetBeans try
> > to ensure all dependant projects are up-to-date. I guess this is
> unnecessary.
>
> Ideally, an IDE should ensure all dependents are up to date when the
> project they depend on changes. Unfortunately, this is a little slow in
> Netbeans since it out-souces the updating to ant which isn’t very
> incremental.
>
> > The usual workflow is to do:
> >
> > $ ./mx build
> >
> > and only then rebuild individual parts in the IDE, right?
>
> With your patch, this will become the *required* workflow for NetBeans
> users. The ‘mx build’ step will probably take as long NetBeans doing the
> updating itself but at least it is an explicit step as opposed to occurring
> each time one edits a file in NetBeans. In Eclipse, this is all somewhat
> faster given that it does more precise propagation of updates.
>
> I propose making this setting conditional on a variable in mx/env.
> Something like:
>
> NETBEANS_UPDATE_DEPENDENTS=false
>
> How does that sound? Of course, the variable would only have an effect
> when running ‘mx netbeansinit’.
>
> -Doug


More information about the graal-dev mailing list