> >> I have serious doubts about releasing this new API until these > >> performance issues are resolved and better proven out from a > >> usability > >> standpoint. > > > > I think LUCENE-1796 has fixed the performance problems, which was > > caused by > > a missing reflection-cache needed for bw compatibility. I hope to > > commit > > soon! > > > > 2.9 may be a little bit slower when you mix old and new API and do > > not reuse > > Tokenizers (but Robert is already adding reusableTokenStream to all > > contrib > > analyzers). When the backwards layer is removed completely or > > setOnlyUseNewAPI is enabled, there is no speed impact at all. > > > > > The Analysis features of Lucene are the single most common place where > people enhance Lucene. Very few add queries, or muck with field > caches, but they do write their own Analyzers and TokenStreams, > etc. Within that, mixing old and new is likely the most common case > for everyone who has made their own customizations, so a "little bit > slower" is something I'd rather not live with just for the sake of > some supposed goodness in a year or two.
But because of this flexibility, we added the backwards layer. The old style with setUseNewAPI was not flexible at all, and nobody would move his Tokenizers to the new API without that flexibility (maybe he uses external analyzer packages not yet updated). With "a little bit" I mean the cost of wrapping the old and new API is really minimal, it is just an if statement and a method call, hopefully optimized away by the JVM. In my tests the standard deviation between different test runs was much higher than the difference between mixing old/new API (on Win32), so it is not really sure, that the cost comes from the delegation. The only case that is really slower is (now minimized cost of creation in TokenStream.<init>, if you not reuse TokenStreams: Two LinkedHashMaps have to be created and setup). But this is not caused by the backwards layer. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
