[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-patch] Patch proposal for Bug 43174
|
Thomas, does this address some of your concern? Unfortunately, we are
unable to limit the number of results the search engine looks for.
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada
Bogdan Gheorghe/Ottawa/IBM@IBMCA
Sent by: cdt-patch-admin@xxxxxxxxxxx
10/08/2003 04:08 PM
Please respond to
cdt-patch@xxxxxxxxxxx
To
cdt-patch@xxxxxxxxxxx
cc
Subject
RE: [cdt-patch] Patch proposal for Bug 43174
And here is just such a patch:
- Added a "Search entire project for completion proposals" check box to
Preferences->C/C++ Editor->Content Assist
- The default is file search scope.
- AutomatedIntegration Suite run on both Windows and Linux.
- Bogdan
Douglas Schaefer/Ottawa/IBM@IBMCA
Sent by: cdt-patch-admin@xxxxxxxxxxx
10/08/2003 01:31 PM
Please respond to
cdt-patch@xxxxxxxxxxx
To
cdt-patch@xxxxxxxxxxx
cc
Subject
RE: [cdt-patch] Patch proposal for Bug 43174
Actually, John C corrected me. Not only is it the widget size but that
the Search Engine, for each match that it finds, opens the file with the
declaration for that match and parses it. I imagine we can find a more
optimal solution for 2.0.
For now, I think the best answer is the preference to select File scope
versus Project scope. We'll have File scope as the default which can be
overridden by products as necessary.
Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada
Thomas Fletcher <ThomasF@xxxxxxx>
Sent by: cdt-patch-admin@xxxxxxxxxxx
10/08/2003 01:12 PM
Please respond to
cdt-patch@xxxxxxxxxxx
To
"'cdt-patch@xxxxxxxxxxx'" <cdt-patch@xxxxxxxxxxx>
cc
Subject
RE: [cdt-patch] Patch proposal for Bug 43174
> -----Original Message-----
> From: Douglas Schaefer [mailto:dschaefe@xxxxxxxxxx]
> Sent: October 8, 2003 12:05 PM
> To: cdt-patch@xxxxxxxxxxx
> Subject: RE: [cdt-patch] Patch proposal for Bug 43174
>
>
> The root cause of the problem we saw was when the code
> completion returned
> a large result set. The performance problem wasn't in the
> search but in
> the creation of the drop down. The fix produced by Bogdan is
> unfortunately only a workaround for that to try and reduce
> the size of the
> set.
>
> BTW, we were getting code complete times of 3 minutes + with no
> opportunity to cancel which would look like a hang to the user.
Aha! Now I'm getting a better understanding. In that case, I
would suggest a preference instead which limits the number of
entries returned to the user. Since entries get ranked as they
are put into code completion, and typing "more" causes the list
to get narrowed down, then limitting the number of entries
presented (ie a random semi large number like 250?) seems more
than reasonable.
Limiting the scope of the returned values because the widgets
don't handle large data sets seems to be punishing some users
while not doing justice to the wicked work you guys have done
on the searching/indexing.
Thomas
> cdt-patch-admin@xxxxxxxxxxx wrote on 10/08/2003 11:45:42 AM:
>
> >
> >
> > > -----Original Message-----
> > > From: Alain Magloire [mailto:alain@xxxxxxx]
> > > Sent: October 8, 2003 10:55 AM
> > > To: cdt-patch@xxxxxxxxxxx
> > > Subject: Re: [cdt-patch] Patch proposal for Bug 43174
> > >
> > > +1, with some comments.
> > >
> > > (1)
> > > If the file search scope includes the inclusion ("#include ...")
> > > part of the search, got no problem.
> > > True for C it is not a requirement for visibility, in the IDE
> > > case making an explicit declaration should be a requirement for
> > > Code Assist to work properly.
> >
> > Fully agree with this. One of the major feature parity issues
> > which customers (of the CDT and derived products) have is the
> > fact that we _do_ have code completion for projects.
> >
> > I can certainly explain to existing customers about the necessity
> > (ie performance improvement) of only providing information from
> > included header files (promote proper developer discipline, clean
> > code yadadada). I can _not_ realistically tell them that the entire
> > feature is _just_gone_ and that they will have to live with it.
> >
> > > (2)
> > > I do understand that the first time, you do content assit
> > > you will have a hit, but do not we have cache indexed file
> > > to speed things up ?
> > >
> > > (3)
> > > The old indexer(CTags) parse the entire project once
> > > in a database, and all globals would be indexed so
> > > next time around even for a big project, it would not
> > > take more then a few seconds.
> >
> > I think that there is likely some extra work being done here that
> > Alex Chapiro is discussing in another thread.
> >
> > Thanks,
> > Thomas
> >
> >
> > > > JohnC
> > > >
> > > > cdt-patch-admin@xxxxxxxxxxx wrote on 10/08/2003 05:54:36 AM:
> > > >
> > > > >
> > > > > What's the problem?
> > > > >
> > > > > In its current state, code assist takes a long time to pop up
> > > > > completions and they aren't always correct.
> > > > >
> > > > > Why?
> > > > >
> > > > > Code assist currently uses a project scope when performing a
> > > > > search. Thus all files in a project are searched - which
> > > > > contributes to the long pop up time (especially in large
> > > projects)
> > > > > and the inaccurate results (as a file rarely includes all
> > > > > the other files in the same project).
> > > > >
> > > > > What's in this patch?
> > > > >
> > > > > This patch changes the search scope for code assist from
> > > a project
> > > > > scope to a file scope. This improves both performance and
> > > > > accuracy of the matches.
> > > > >
> > > > > Automation Suite run on both Windows + Linux.
> > > > >
> > > > > Thanks,
> > > > > Bogdan
> > > > > [attachment "cdt-core-patch.txt" deleted by John
> > > Camelon/Ottawa/IBM]
> > > > > [attachment "cdt-ui-patch.txt" deleted by John
> > > Camelon/Ottawa/IBM]
> > > > _______________________________________________
> > > > cdt-patch mailing list
> > > > cdt-patch@xxxxxxxxxxx
> > > > http://dev.eclipse.org/mailman/listinfo/cdt-patch
> > > >
> > > >
> > > > _______________________________________________
> > > > cdt-patch mailing list
> > > > cdt-patch@xxxxxxxxxxx
> > > > http://dev.eclipse.org/mailman/listinfo/cdt-patch
> > > >
> > >
> > >
> > > --
> > > au revoir, alain
> > > ----
> > > Aussi haut que l'on soit assis, on est toujours assis que sur
> > > son cul !!!
> > >
> > > _______________________________________________
> > > cdt-patch mailing list
> > > cdt-patch@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/cdt-patch
> > >
> > _______________________________________________
> > cdt-patch mailing list
> > cdt-patch@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-patch
>
> _______________________________________________
> cdt-patch mailing list
> cdt-patch@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-patch
>
_______________________________________________
cdt-patch mailing list
cdt-patch@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-patch
_______________________________________________
cdt-patch mailing list
cdt-patch@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-patch
#### cdt-ui-patch.txt has been removed from this note on October 09, 2003
by Douglas Schaefer
#### cdt-core-patch.txt has been removed from this note on October 09,
2003 by Douglas Schaefer
