Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Indexer conf call?
Ok, I'm willing to be pleasantly surprised :-). Let's wait and see what the benchmarks show. 

Cheers,

Greg
p.s. Thanks for working your *ss off! We all appreciate the improvement it has made to CDT. 


On Mar 16, 2007, at 10:54 AM, Doug Schaefer wrote:
No, my objection is that I think there is a better solution that minimizes the impact on the rest of the CDT while still making your customers happy.
Instead of discussion the what if's, I really want to see the benchmarks. 
Having worked my *ss off to improve the performance of the indexer by
ensuring each file is only parsed once, I think you'll be pleasantly
surprised by the performance using remote files, even with large projects.
And remember this is only done once, all things like call hierarchy, content assist, open decl, wouldn't need to parse remote files at all. We also have a feature request to prebuild indexes as part of builds. If we worked on 
that instead, it would even be faster.
But that is my opinion, and I don't have access to these environments to 
test, and I am easily swayed by facts.
And all that being said, if this was truly only a remote indexing solution, I would be O.K. with it. We have the interfaces to support that. My real problem is with putting the clients remote as well, especially since these will continue to evolve, likely by people who know little about the remote 
story, and will be faced by this interface in the middle of the code.
Again, I am one voice and I will go with the flow if I feel I'm the only one who feels this way. I do need to speak now to ensure that that we are truly doing the right thing for all CDT users. There are lots of them now, I'd say almost a half a million, I want to make sure we aren't compromising their 
features either.
And I think I've said all I have to. My ears and mind are open. Let wisdom 
prevail :).

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com



-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev- bounces@xxxxxxxxxxx] On 
Behalf Of Greg Watson
Sent: Friday, March 16, 2007 12:36 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Indexer conf call?

Doug,

Is your objection really that there will only be one client of remote
indexing (although PTP will likely use it also)? If this is the case,
then does that mean that only features that are used by many
companies will ever be available in CDT? It seems a kind of
restrictive policy.

I understand the reluctance to introduce more complexity into CDT,
but I think that the benchmarks will find that the performance of
indexing large projects via a remote filesystem will be abysmal. File
system operations tend to be very low level, and both the indexing
operation and accessing the index remotely will likely result in a
much larger amount of network traffic that simply accessing a remote
database. Since we're dealing with millions of lines of code, I don't
think this indexing model will be scalable.

Cheers,

Greg

On Mar 15, 2007, at 2:44 PM, Doug Schaefer wrote:


I'm not totally sure what you guys are talking about. If you are
talking
about the DAO thing, I don't consider that an API of the CDT. In
fact I'd
rather people not know about it. It is a hack to allow the IBM to
tear apart
the CDT at their whim while adding complexity to an already too
complex
architecture. No one else will benefit from it. Did I mention I
really don't
like this thing? ;) Until someone shows me the real costs, I will
continue
to believe that indexing locally and accessing the files over the
wire is
the correct architecture, especially now that the CDT never parses an 
unchanged file more than once.

So as such, the DAO interface can be changed whenever.

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com


-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-
bounces@xxxxxxxxxxx] On
Behalf Of Chris Recoskie
Sent: Thursday, March 15, 2007 4:08 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Indexer conf call?

Hi Andrew,
I'm not sure if you mean whether we (IBM) have slack in terms of our 
schedule for getting the items in before the freeze, or if you mean
whether
we have slack as to what release of CDT they would go in.

I'll try to answer both questions.
If (big if...) we were going to move all the clients to the DAO model 
(call
hierarchy, type hierarchy, search, etc.), our internal schedule
says we
would be done this in early to mid April (I can break this down in
detail
if anyone is interested).  If the work only has to make the
feature freeze
then there is a couple of weeks of slack.  We didn't get consensus
yet
that
everyone has a warm fuzzy feeling about migrating all the clients
though.
For those clients that have already a good separation of UI and
back end
such as the call hierarchy and type hierarchy this would be a
relatively
simple process, but for other clients it might or might not take
more work
to factor out the back end. For our part we are very concerned with 
making
sure that quality is maintained and we've been rigorously running
the UI
tests to make sure we haven't been breaking anything.

In terms of CDT releases, that probably bears some discussion and
clarification...

Markus was concerned about making it for API freeze... I guess the
questions we need to answer are what are our (as in CDT's) APIs
going to
be
and are we actually prepared to freeze them in two weeks given that
feature
work is ongoing up until April 30th.  Some things are obviously
going to
be
API (IIndex and the like, new project model stuff, etc.) but in
terms of
the back end to the views and other index based services it's not
very
clear to me what is going to be API and what isn't.

What is API and what is not has a lot of ramifications...

- What are we freezing for API freeze?  Are we in fact freezing at
M6?
Personally I'm not sure it's practical to freeze API prior to
feature work
being done unless the system is very mature (i.e., if you are the
Eclipse
Platform and are not implementing a huge amount of features in this 
release you have a much easier time of freezing API ahead of your
feature
delivery than we do).  That's just my $0.02 CDN though...

- What can and cannot be put in between M6 and the feature freeze?

- What can and cannot be done in CDT 4.1 that doesn't make it into
CDT
4.0?
In a 4.1 we can add new API but can't break existing API.  To break
existing API we'd need a CDT 5.0, which would be a year from now.

In terms of our own desires at IBM, a year is a long time to wait
because
it doesn't line up well with our product release cycle (it already
takes
almost a year for us to deploy products based on CDT, so it would be 
basically two years before anything consuming our proposed
functionality
would see the light of day if we had to wait until CDT 5.0 to get the changes in). It likely suits our purposes well enough if we can get 
something done this year, and we are not entirely picky about which
release
that would be so long as the changes happen and we are not
restricted by
the versioning rules.

What are people's thoughts on the API issues?

===========================

Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt




  From:   Andrew.Ferguson@xxxxxxxxxxx

  To:     "CDT General developers list." <cdt-dev@xxxxxxxxxxx>

  Date:   15/03/2007 03:06 PM

  Subject Re: [cdt-dev] Indexer conf call?
  :






hi,

I've posted minutes for the meeting here:
http://wiki.eclipse.org/index.php/CDT/calls/ IndexingMar2007_1 
if I've missed anything then please add it in.

We ran out of time at the end, just as we were discussing the
scale of
changes proposed. My next
question was going to be if you have any slack in terms of whether
these
changes make CDT 4.0?

thanks,
Andrew
******************************************************************* ** 
*
Symbian Software Ltd is a company registered in England and Wales
with
registered number 4190020 and registered office at 2-6 Boundary Row, 
Southwark, London, SE1 8HP, UK. This message is intended only for
use by
the named addressee and may contain privileged and/or confidential
information. If you are not the named addressee you should not
disseminate,
copy or take any action in reliance on it. If you have received this message in error please notify postmaster@xxxxxxxxxxx and delete the 
message and any attachments accompanying it immediately. Neither
Symbian
nor any of its Affiliates accepts liability for any corruption,
interception, amendment, tampering or viruses occurring to this
message in
transit or for any message sent by its employees which is not in
compliance
with Symbian corporate policy.
******************************************************************* ** 
*
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top