[
https://issues.apache.org/jira/browse/SOLR-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248722#comment-17248722
]
Mark Robert Miller edited comment on SOLR-14848 at 12/14/20, 2:58 AM:
----------------------------------------------------------------------
Well, I’ve slept all weekend, this kind of life style came much easier with a
teenage body and natural inclination vs forced march. I’m essentially ready
here, but I’m tired, blown out, etc etc. And I hate to look, but I’m guessing
Xmas is tomorrow or something. So likely nothing to show until the new year.
was (Author: markrmiller):
Well, I’ve slept all weekend, this kind of life style came much easier with a
teenage body and natural inclination for forced march. I’m essentially ready
here, but I’m tired, blown out, etc etc. And I hate to look, but I’m guessing
Xmas is tomorrow or something. So likely nothing to show until the new year.
> 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
> Reporter: Mark Robert Miller
> Priority: Major
>
> 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
