On 9/6/07, Tom Walter <tom.walter@hitwise.com> wrote:
> Hmm. Thanks for the tip however cleanup doesn't stop it. There is about
> 4000+ files in the project, I guess maybe it is an eclipse platform issue,
> asking subclipse to redecorate unneccessarily, and the redecoration just
> takes a long time because I am computing deep status on such a large number
> of files.
>
> Thanks anyway.
>
> If I were to put in a feature/bug report somewhere to have someone check
> why eclipse is requesting redecoration on files that haven't changed, which
> project would that be best in, Eclipse Platform?
Probably Platform, maybe Team. My guess is that it does this check to
accommodate tools that are doing pessimistic locking as the state of
the file may have changed. Have you actually turned off that
preference and seen the flickering go away? My understanding is that
the Subclipse cache management had gotten very fast and efficient. It
is not like we scan all 4000 files.
The decorator code works off a cache and the cache gets told by
Eclipse when something has changed and needs to be refreshed. So not
really sure why you are seeing this.
Maybe you could replicate it with a large public project, like
something in the Apache project repository? If so, then that would
give me and other devs a chance to try to recreate the issue and see
if there are more optimizations to make.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Sep 7 22:53:52 2007