Mark Robert Miller created SOLR-14848:
-----------------------------------------
Summary: Demonstrate how Solr 8, master, or any version previous
Solr version before pales next to the reference branch.
Key: SOLR-14848
URL: https://issues.apache.org/jira/browse/SOLR-14848
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mark Robert Miller
I've got a lot of code here and I have and will be claiming that it's an order
of magnitude better than what has come before.
I've been too busy and will be busy for a bit, so I have not been too concerned
about backing that up really at all. Most people have no clue what I have here,
some people have an inkling, some people are just totally confused, some people
think I maybe have some fast tests, or a slightly more stable system, or maybe
some neato performance changes, or even maybe some poorly coded speed hacks.
Maybe one or two has a more hope filled guess.
Almost everyone will think, "all that new code, mostly done by a single person?
I know a lot of smart and smarter devs, who cares what this guy is up to. Why
would I leave the safety of the branch I know and feel safe with? By
definition, the existing stuff is the battle hardened, tried and true leader,
and how are you going to come in here without disrupting our comfortable thing?"
Well, fair enough. I won't try to come and disrupt anything. Instead, there
will be benchmarks, stress tests, chaos monkeys, long term endurance tests, and
all sorts of fun competitions. Spy vs Spy. I mean Solr vs Solr.
And while this vanilla version of my previous work has avoided a lot of great
changes and improvements I can make (a "remastered" Solr sensible, initial
mandate that puts a hand or two behind my back) ...
... The reference branch will trounce previous versions of Solr in benchmark
after benchmark. It will keep pumping through endurance tests and performance
challenges at impressive speed while Solr proper will struggle to finish in a
reasonable time or almost certainly, often enough, simply fail to complete the
task. The reference branch will devour available resources and fly through
work. Solr master will struggle and meander, sometimes in the wrong direction,
while leaving the hardware with gobs of idle cpu to chill with (unless it's
using most of the cpu for garbage collection at some points).
This is not meant to brag or dis previous versions of Solr. I was heavily
involved in building them. This is the result of dedication and time more than
any of my brilliance - the above is simply meant to state the path that I see
coming. As this comparison information and other experiences and stories start
to emerge, that master branch won't look nearly so safe or comfortable anymore.
And it's at that point that we will find out if anyone is interested in testing
our tolerance for disruption by trying to figure out how to get master into the
reference branch as opposed to the other way around.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
