NetBeans Forums
| View previous topic :: View next topic |
| Author |
Message |
laurentapo
Joined: 20 Nov 2008
Posts: 7
|
 Posted: Thu Nov 20, 2008 10:43 am Post subject: Task scanning |
 |
|
Hello,
I try to use new NetBeans 6.5 before I used 5.5.1.
I work on layered project (Persistence, Business Objects, Business Layer, Web services server, Web services client, Rcp Swing-Jws)
Each layer is separate in modules (common, planning, billing, ...)
So I have many projects (25) and lot of classes (2850).
Projects are linked with jar, they do not reference to an other project.
When I compile a project, with ant I copy dist/myProject.jar to a directory /libs/. Projects reference jars in this directory.
With 6.5 when I compile a project, NetBeans run "task scanning" and it use 100% of CPU, so it's very slow and it takes many minutes.
Thanks for your help
Laurent |
|
| Back to top |
|
 |
Nigel Leck
Posted via mailing list.
|
| Posted: Sun Nov 23, 2008 9:29 pm Post subject: Task scanning |
|
|
I turned it off.
Under Tools->plugins
laurentapo wrote: | Quote: | | Quote: | Hello,
I try to use new NetBeans 6.5 before I used 5.5.1.
I work on layered project (Persistence, Business Objects, Business Layer, Web services server, Web services client, Rcp Swing-Jws)
Each layer is separate in modules (common, planning, billing, ...)
So I have many projects (25) and lot of classes (2850).
Projects are linked with jar, they do not reference to an other project.
When I compile a project, with ant I copy dist/myProject.jar to a directory /libs/. Projects reference jars in this directory.
With 6.5 when I compile a project, NetBeans run "task scanning" and it use 100% of CPU, so it's very slow and it takes many minutes.
Thanks for your help
Laurent
|
|
--
Regards,
Nigel's STS email signature tag file
Nigel Leck
ST Software
t +61 2 9975 4648 f +61 2 9975 4652
Ground Floor / Suite 2 / Building C
No. 14 Rodborough Rd Frenchs Forest NSW 2086
PO Box 6275 Frenchs Forest NSW 2086
address-removed ([email]address-removed[/email]) www.stsoftware.com.au
If you receive this email by mistake, please notify us and do not use it. We do not waive any privilege, confidentiality or copyright associated with this email.
Liability limited by a scheme approved under Professional Standards Legislation. |
|
| Back to top |
|
|
melc
Joined: 24 Nov 2008
Posts: 12
|
| Posted: Mon Nov 24, 2008 2:07 pm Post subject: |
|
|
Can you please explain exactly how you deactivated "Scanning projects..." function in Netbeans6.5?
Thanks |
|
| Back to top |
|
|
Petr Dvorak
Posted via mailing list.
|
| Posted: Mon Nov 24, 2008 7:17 pm Post subject: Task scanning |
|
|
You don't - it has to be done, otherwise almost no Java related stuff
wouldn't work. It has been discussed here many times... Improvements are
planned for 7.0, but it probably still won't be possible to turn project
scanning (etc.) off...
Petr Dvorak
melc wrote:
| Quote: | Can you please explain exactly how you deactivated "Scanning projects..." function in Netbeans6.5?
Thanks
|
|
|
| Back to top |
|
|
Gregg Wonderly
Posted via mailing list.
|
| Posted: Mon Nov 24, 2008 10:59 pm Post subject: Task scanning |
|
|
Petr Dvorak wrote:
| Quote: | You don't - it has to be done, otherwise almost no Java related stuff
wouldn't work. It has been discussed here many times... Improvements are
planned for 7.0, but it probably still won't be possible to turn project
scanning (etc.) off...
|
Petr, would there be a good place to discuss what the developers believe the
scanning is doing for them that can not be done by in context actions that the
user initiates as they need the information the scanning is collecting?
I am still unsure that anything but badging really needs to do this, and the
types of things that badging reveals, does not seem to have the bang for the
buck spent because users have to wait all the time.
I'd really like to know what the impetus is behind this activity and why it is
deemed as so necessary when it has such a negative impact on users.
Gregg Wonderly |
|
| Back to top |
|
|
Nigel Leck
Posted via mailing list.
|
| Posted: Tue Nov 25, 2008 12:00 am Post subject: Task scanning |
|
|
Task scanning and project scanning are different things...
Task scanning is optional and can be turned off in the tools->plugins
With project scanning... when we do bulk moving of files around deleting renaming we really need to be able to turn it off ( if it can't be made non-blocking). At the moment when we need to move a number of files around we go back to the command line do it there and then come back to the ide and do a full compile.
Gregg Wonderly wrote: | Quote: | Petr Dvorak wrote:
| Quote: | You don't - it has to be done, otherwise almost no Java related stuff wouldn't work. It has been discussed here many times... Improvements are planned for 7.0, but it probably still won't be possible to turn project scanning (etc.) off...
|
Petr, would there be a good place to discuss what the developers believe the scanning is doing for them that can not be done by in context actions that the user initiates as they need the information the scanning is collecting?
I am still unsure that anything but badging really needs to do this, and the types of things that badging reveals, does not seem to have the bang for the buck spent because users have to wait all the time.
I'd really like to know what the impetus is behind this activity and why it is deemed as so necessary when it has such a negative impact on users.
Gregg Wonderly
|
--
Regards,
Nigel's STS email signature tag file
Nigel Leck
ST Software
t +61 2 9975 4648 f +61 2 9975 4652
Ground Floor / Suite 2 / Building C
No. 14 Rodborough Rd Frenchs Forest NSW 2086
PO Box 6275 Frenchs Forest NSW 2086
address-removed ([email]address-removed[/email]) www.stsoftware.com.au
If you receive this email by mistake, please notify us and do not use it. We do not waive any privilege, confidentiality or copyright associated with this email.
Liability limited by a scheme approved under Professional Standards Legislation. |
|
| Back to top |
|
|
melc
Joined: 24 Nov 2008
Posts: 12
|
| Posted: Tue Nov 25, 2008 9:12 am Post subject: |
|
|
| Also after a build of a project (as I have described in http://forums.netbeans.org/viewtopic.php?t=4991&highlight=) with about 700 files related to other say 3 projects with plenty of files each, even though the project compiles it may start scanning and not let you run/debug the project which i suppose is irrelevant, since project scanning should have to do only with the IDE functionality. |
|
| Back to top |
|
|
artisan
Joined: 25 Nov 2008
Posts: 23
|
| Posted: Tue Nov 25, 2008 11:48 am Post subject: |
|
|
Personally I don't mind the IDE scanning for tasks, validating code, etc... Otherwise there is no way to see the feedback put into code. Even if it takes several minutes and noticeable CPU load.
But what's really killing me is that the IDE does it all over again each time it starts. Why not 'remember' what the previous task scanning did ? Or is there a way to do this already ? |
|
| Back to top |
|
|
Jiri Prox
Posted via mailing list.
|
| Posted: Thu Nov 27, 2008 8:50 am Post subject: Task scanning |
|
|
Hi,
the scanning on startup is performed to find changes in sources which
may have done while IDE was off. In 6.5 it should only timestamps and
hashes to identify source roots which are changed. such root is than
scanned, otherwise the scanning of source root is skipped and cached is
used instead of it.
Regards
Jirka
artisan wrote:
| Quote: | Personally I don't mind the IDE scanning for tasks, validating code, etc... Otherwise there is no way to see the feedback put into code. Even if it takes several minutes and noticeable CPU load.
But what's really killing me is that the IDE does it all over again each time it starts. Why not 'remember' what the previous task scanning did ? Or is there a way to do this already ?
|
|
|
| Back to top |
|
|
artisan
Joined: 25 Nov 2008
Posts: 23
|
| Posted: Thu Nov 27, 2008 9:03 am Post subject: Re: Task scanning |
|
|
| Jiri Prox wrote: | Hi,
the scanning on startup is performed to find changes in sources which
may have done while IDE was off. In 6.5 it should only timestamps and
hashes to identify source roots which are changed. such root is than
scanned, otherwise the scanning of source root is skipped and cached is
used instead of it.
Regards
Jirka
|
That's weird. Because the project I checked out about a week ago gets scanned every time I start the IDE. And I am quite sure no changes were made locally. As the project is quite vast it takes quite a while to have it scanned completely.
I'm using NetBeans 6.5 on Kubuntu 8.10, using JRE build '1.6.0_10-b33'. Maybe there's a difference for Linux versions ? |
|
| Back to top |
|
|
melc
Joined: 24 Nov 2008
Posts: 12
|
| Posted: Thu Nov 27, 2008 12:23 pm Post subject: |
|
|
I don't think there is a difference in linux the same happens in win xp with large projects(1000 files).... after playing with classpath or code (editing or adding removing a file maybe) for a while and then compile, which i do in order to run/debug the project, I simply wait... for many minutes in order to finish project scanning. Only when it finishes i'm able to run  |
|
| Back to top |
|
|
artisan
Joined: 25 Nov 2008
Posts: 23
|
| Posted: Thu Nov 27, 2008 3:51 pm Post subject: |
|
|
The project is a Maven2 project. Maybe it's a bug in the plugin ?
Anyway, I can have a cup of coffee each time the IDE starts.  |
|
| Back to top |
|
|
Gregg Wonderly
Posted via mailing list.
|
| Posted: Mon Dec 01, 2008 7:40 pm Post subject: Task scanning |
|
|
artisan wrote:
| Quote: | Personally I don't mind the IDE scanning for tasks, validating code, etc... Otherwise there
is no way to see the feedback put into code. Even if it takes several minutes
|
and noticeable CPU load.
| Quote: |
But what's really killing me is that the IDE does it all over again each time it starts. Why not
'remember' what the previous task scanning did ? Or is there a way to do this
|
already ?
Okay, this is where the old MDR system went I think... The number one issue for
me, is that it is impossible to have this "disconnected" view of the state of a
source file. I can, independently of the IDEs actions, change the contents of
the underlying source trees with my SCM, or other activity, and completely
invalidate any cached data. Once that happens, it will be necessary for the IDE
to "rescan" the changed files and make the appropriate decisions on what is
actually the "state of the world". While it is doing that non-zero time
scanning, things can change again and again from outside tools and actions, so
it really is impossible for the IDE to look at source files in any asynchronous
way and consume the contents without having moments of disconnect.
The kids at IBM, tried to solve this problem in Visual Age for Java (remember
that?) by making sure there were no visible source files. The people with
arbitrary SCMs, were not provided for in that mechanism. If you used IBMs SCM,
you were good to go.
With eclipse, they finally figured out that if you create a very small view of
what might possibly change, and you make your parser coupled to only that view,
then you can go as fast as the user can edit. Thus, they created the "one line
at a time" compilation mechanisms. If you switch editing contexts, only at that
moment will the source file be reparsed. But, it seems to remember the last set
of meta-data about the source file that it had, and uses that as the starting point.
It also seems that there are other things going on as secondary checks for
making sure builds will build all appropriate bits.
This is an age old problem. People have forever tried to make incremental
parsing and badging and global builds all work together to always have the
complete view. The issue is, that it is possible to change enough about the
source tree, that it will take a non-finite and non-small amount of time to
compute a new "view of the world".
My assertion is that this can change so often and so globally in Java
development, that it's more impact to the developers overall productivity than
the value that it adds by providing badging which might help the developer to
take care of the appropriate issues, before issuing a build that will reveal all
those issues itself.
I am a strong proponent of build completely, early and often. Componentize your
software so that this is possible and easy to do, and then you don't need the
IDE running around doing extra builds for you because you'll find out the same
information that it is trying to tell you every minute, when you build at the
5-10minute intervals that you would anyway.
I get more productivity out of having a fast and unburdening editing environment
than I do out of the badging.
Gregg Wonderly |
|
| Back to top |
|
|
marc.farrow
Joined: 15 Aug 2008
Posts: 157
Location: South Carolina
|
| Posted: Mon Dec 01, 2008 7:44 pm Post subject: Task scanning |
|
|
I don't have anything else useful to say, because the task scanning has never really hindered me so much.
But I will say that this is an excellent post. Well presented without badgering other people's views, etc. So maybe the best option would be to add a way to disable this "task scanning".
Marc
On Mon, Dec 1, 2008 at 2:39 PM, Gregg Wonderly <address-removed ([email]address-removed[/email])> wrote:
| Quote: | artisan wrote:
| Quote: | Personally I don't mind the IDE scanning for tasks, validating code, etc... Otherwise there
|
> is no way to see the feedback put into code. Even if it takes several minutes and noticeable CPU load.
| Quote: |
But what's really killing me is that the IDE does it all over again each time it starts. Why not
|
> 'remember' what the previous task scanning did ? Or is there a way to do this already ?
Okay, this is where the old MDR system went I think... The number one issue for me, is that it is impossible to have this "disconnected" view of the state of a source file. I can, independently of the IDEs actions, change the contents of the underlying source trees with my SCM, or other activity, and completely invalidate any cached data. Once that happens, it will be necessary for the IDE to "rescan" the changed files and make the appropriate decisions on what is actually the "state of the world". While it is doing that non-zero time scanning, things can change again and again from outside tools and actions, so it really is impossible for the IDE to look at source files in any asynchronous way and consume the contents without having moments of disconnect.
The kids at IBM, tried to solve this problem in Visual Age for Java (remember that?) by making sure there were no visible source files. The people with arbitrary SCMs, were not provided for in that mechanism. If you used IBMs SCM, you were good to go.
With eclipse, they finally figured out that if you create a very small view of what might possibly change, and you make your parser coupled to only that view, then you can go as fast as the user can edit. Thus, they created the "one line at a time" compilation mechanisms. If you switch editing contexts, only at that moment will the source file be reparsed. But, it seems to remember the last set of meta-data about the source file that it had, and uses that as the starting point.
It also seems that there are other things going on as secondary checks for making sure builds will build all appropriate bits.
This is an age old problem. People have forever tried to make incremental parsing and badging and global builds all work together to always have the complete view. The issue is, that it is possible to change enough about the source tree, that it will take a non-finite and non-small amount of time to compute a new "view of the world".
My assertion is that this can change so often and so globally in Java development, that it's more impact to the developers overall productivity than the value that it adds by providing badging which might help the developer to take care of the appropriate issues, before issuing a build that will reveal all those issues itself.
I am a strong proponent of build completely, early and often. Componentize your software so that this is possible and easy to do, and then you don't need the IDE running around doing extra builds for you because you'll find out the same information that it is trying to tell you every minute, when you build at the 5-10minute intervals that you would anyway.
I get more productivity out of having a fast and unburdening editing environment than I do out of the badging.
Gregg Wonderly
|
|
|
| Back to top |
|
|
Gregg Wonderly
Posted via mailing list.
|
| Posted: Mon Dec 01, 2008 8:49 pm Post subject: Task scanning |
|
|
Gregg Wonderly wrote:
| Quote: | I am a strong proponent of build completely, early and often.
Componentize your software so that this is possible and easy to do, and
then you don't need the IDE running around doing extra builds for you
because you'll find out the same information that it is trying to tell
you every minute, when you build at the 5-10minute intervals that you
would anyway.
I get more productivity out of having a fast and unburdening editing
environment than I do out of the badging.
|
Also, let me add, that I do enjoy using things such as "CTRL-R" renaming and
other such things that do make use of the source tree meta-data to try and
provide renaming at a wider view than the current source file. This is the type
of thing which is a benefit to many users because it is something that normal
compilation can tell you (you rename a field and 100 references are now wrong),
but which the users time spent fixing would be much reduced by the use of the
meta-data to know what editing to do automatically (There is the secondary issue
of SCM interaction with SCMs like perforce that might need to check files out
for that editing, which are not supported in the IDE directly).
Gregg Wonderly |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
