You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Earwin Burrfoot <ea...@gmail.com> on 2009/05/21 16:17:36 UTC
SegmentReader instantiation
Right now a set of system properties and Class.newInstance() is used
to create SegmentReader.
I've tracked down this code's origins to:
r150531 | cutting | 2004-09-22 22:32:27 +0400 (ср, 22 сен 2004) | 2 lines
Add GCJ native code for SegmentTermDocs.read(int[],int[]) to
accellerate TermScorer. TermScorer and BooleanScorer are now usually
a bit faster under GCJ than under Sun's JVM.
Anybody uses this? Let's just go ahead, scrap it, and construct
classes using er.. constructors? :)
No adequate docs for this feature exist, except a very brief mention
in CHANGES.txt.
Even more - when ReadonlySegmentReader was introduced, instantiation
code was blindly copypasted, but no matching GCJReadonlySegmentReader
was created and corresponding Makefile wasn't altered, thus
GCJ-optimized Lucene is currently broken on trunk.
Removal of this feature also won't break any theoretical old apps that
magically happen to use it, because we'll simply ignore the property
with zero change in runtime behaviour.
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: SegmentReader instantiation
Posted by DM Smith <dm...@gmail.com>.
Michael McCandless wrote:
> On Thu, May 21, 2009 at 10:53 AM, Earwin Burrfoot <ea...@gmail.com> wrote:
>
>
>>> I agree we should probably remove it, unless there are users relying
>>> on this. Maintaining side-by-side sources is difficult with time.
>>>
>> As I said in the initial message, this feature introduces no runtime
>> behaviour changes, so you can't really 'rely' on it and break if it's
>> removed.
>>
>
> Well maybe someone loves the performance improvement... and took
> it further by making their own native code extensions. I'm not
> sure how much these gains are. But people can get quite crazy when
> it comes to performance :)
>
>
>>> Can you send an email to java-user to take a quick survey on whether
>>> anyone is somehow needing this?
>>>
>> Never subscribed there. Too low signal-to-noise ratio. I can, but ..
>> is it a must? :)
>>
>
> In fact I find many good ideas for improving Lucene come from our
> users, and one can't really understand what's important in Lucene
> without being grounded on how it's used. "Development" and "using" go
> hand in hand.
>
> The discussions that take place there spawn still more ideas, and
> following those dicussions causes me to think harder about the areas
> being discussed, so I learn more myself about Lucene and find
> more things to improve and ponder.
>
> Not to mention when there's a sneaky bug, it usually appears on the
> users list first. I jump a those ;)
>
> So, yeah, I think it is a must. It's likely nobody will respond after
> a few days, then we should remove gcj.
>
> I'll go ask if anyone is relying on gcj native code on java-user.
Fedora uses Lucene for Eclipse and uses gcj for Eclipse. It might be
used elsewhere. Don't know if that means they need the gcj stuff in
Lucene. I just wish they'd rework to use openjdk.
-- DM
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: SegmentReader instantiation
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, May 21, 2009 at 10:53 AM, Earwin Burrfoot <ea...@gmail.com> wrote:
>> I agree we should probably remove it, unless there are users relying
>> on this. Maintaining side-by-side sources is difficult with time.
>
> As I said in the initial message, this feature introduces no runtime
> behaviour changes, so you can't really 'rely' on it and break if it's
> removed.
Well maybe someone loves the performance improvement... and took
it further by making their own native code extensions. I'm not
sure how much these gains are. But people can get quite crazy when
it comes to performance :)
>> Can you send an email to java-user to take a quick survey on whether
>> anyone is somehow needing this?
> Never subscribed there. Too low signal-to-noise ratio. I can, but ..
> is it a must? :)
In fact I find many good ideas for improving Lucene come from our
users, and one can't really understand what's important in Lucene
without being grounded on how it's used. "Development" and "using" go
hand in hand.
The discussions that take place there spawn still more ideas, and
following those dicussions causes me to think harder about the areas
being discussed, so I learn more myself about Lucene and find
more things to improve and ponder.
Not to mention when there's a sneaky bug, it usually appears on the
users list first. I jump a those ;)
So, yeah, I think it is a must. It's likely nobody will respond after
a few days, then we should remove gcj.
I'll go ask if anyone is relying on gcj native code on java-user.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: SegmentReader instantiation
Posted by Earwin Burrfoot <ea...@gmail.com>.
2009/5/21 Michael McCandless <lu...@mikemccandless.com>:
> It looks like this was done in order to implement
> SegmentTermDocs.read(int[], int[]) natively, when using a gcj
> environment, since that gave performance improvements?
Yup, you're right. But something tells me, since Lucene 1.9 many
things changed and this is no longer relevant.
> I agree we should probably remove it, unless there are users relying
> on this. Maintaining side-by-side sources is difficult with time.
As I said in the initial message, this feature introduces no runtime
behaviour changes, so you can't really 'rely' on it and break if it's
removed.
> Can you send an email to java-user to take a quick survey on whether
> anyone is somehow needing this?
Never subscribed there. Too low signal-to-noise ratio. I can, but ..
is it a must? :)
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: SegmentReader instantiation
Posted by Michael McCandless <lu...@mikemccandless.com>.
It looks like this was done in order to implement
SegmentTermDocs.read(int[], int[]) natively, when using a gcj
environment, since that gave performance improvements?
I agree we should probably remove it, unless there are users relying
on this. Maintaining side-by-side sources is difficult with time.
Also, this seems like something source code specialization
(LUCENE-1594) should cover.
Can you send an email to java-user to take a quick survey on whether
anyone is somehow needing this?
Mike
On Thu, May 21, 2009 at 10:17 AM, Earwin Burrfoot <ea...@gmail.com> wrote:
> Right now a set of system properties and Class.newInstance() is used
> to create SegmentReader.
>
> I've tracked down this code's origins to:
> r150531 | cutting | 2004-09-22 22:32:27 +0400 (ср, 22 сен 2004) | 2 lines
> Add GCJ native code for SegmentTermDocs.read(int[],int[]) to
> accellerate TermScorer. TermScorer and BooleanScorer are now usually
> a bit faster under GCJ than under Sun's JVM.
>
> Anybody uses this? Let's just go ahead, scrap it, and construct
> classes using er.. constructors? :)
> No adequate docs for this feature exist, except a very brief mention
> in CHANGES.txt.
> Even more - when ReadonlySegmentReader was introduced, instantiation
> code was blindly copypasted, but no matching GCJReadonlySegmentReader
> was created and corresponding Makefile wasn't altered, thus
> GCJ-optimized Lucene is currently broken on trunk.
> Removal of this feature also won't break any theoretical old apps that
> magically happen to use it, because we'll simply ignore the property
> with zero change in runtime behaviour.
>
> --
> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
> ICQ: 104465785
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org