[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdt-dev] H2 index in DLTK
- From: Alex Panchenko <alex@xxxxxxxxx>
- Date: Fri, 5 Mar 2010 14:56:53 +0600 (NOVT)
- Delivered-to: firstname.lastname@example.org
The 1st design question: why H2-indexing doesn't use ISourceElementParser to automatically index model element declarations?
This way should be easier for adopters as they don't need to implement one more interface.
And IIndexingParser can become optional, to report additional information.
What do you think?
----- Original Message -----
From: "Alex Panchenko" <alex@xxxxxxxxx>
To: "PDT Developers" <pdt-dev@xxxxxxxxxxx>
Sent: Monday, March 1, 2010 11:51:14 PM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [pdt-dev] H2 index in DLTK
----- Roy Ganor wrote:
> Hi Alex,
> Moving to the h2-based index by default makes perfectly sense as many
> PDT users reported significant performance improvements. It will also
> make the people worked on this method very happy ;)
> We don't have any internal tests for this method but all tests that
> currently work on top of the h2-indexing itself should provide a good
> picture on possible flaws.
> Several questions that cross my mind:
> 1. Will DLTK bundle/maintain the basic index mechanism (not the
> h2-one). Can we make it as an extra feature like h2-index is now?
That's why I am touching it: I would like to avoid having 2 index implementations.
> 2. Since currently h2 database is available in a more updated version
> as confirmed by Eclipse IP process (1.117) it will make sense to not
> bundle h2 inside the plugin/feature but leave adopters to use whatever
> version they want.
I always was for making h2.jar available externally :)
But we need to check that Helios build can find it somewhere.
> 3. There is a nice framework (org.eclipse.test.performance) that
> Michael contributed that checks for performance regressions. It will
> be nice to run it under the two methods and provide a benchmark. Do
> you think DLTK build system can monitor changes and provide it?
org.eclipse.test.performance can compare performance metrics of different versions(builds) of the same tests.
We tried it for some time, but it's disabled now to reduce build time.
> 4. Using the h2-based index is a big step forward, however there is
> always a place for improvement. Since PDT is currently the (only
> AFAIK) one that adopts this plugin, it makes sense to consult in this
> forum before changes are done.
Definitely we'll discuss the changes first.
> Best regards,
> -----Original Message-----
> From: pdt-dev-bounces@xxxxxxxxxxx [mailto:pdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Alex Panchenko
> Sent: Monday, March 01, 2010 5:34 PM
> To: PDT Developers
> Subject: [pdt-dev] H2 index in DLTK
> Hi all,
> I was looking if it makes sense to move all DLTK indexing into H2.
> And if DLTK will go this way probably I'll make some changes to these
> Do you have any concerns about it?
> And the related question: do you have any standalone unit tests for
> the index implementation?
> Thank you,
> pdt-dev mailing list
> pdt-dev mailing list