Robert Muir

Low-overhead profiling

15

I think the benchmark results would be more useful if we could see some basic analysis of the code under load. We could imagine summary tables, graphs, flame charts, whatever...

Currently the test suite is run with tons of cpus on mike's computer. The issue is, not everyone has 64 cores (e.g. I have 2). any slowdowns to the tests...

Currently the data being searched fits in RAM, so the benchmark is cheating in a way. For example: adding or removing random accesses probably wouldn't even register a blip. But...

metrics such as P99.9 are wrong

1

Unless tens/hundreds of thousands of searches are run by the benchmark, P99.9 should not be reported.

Today, you can use an annotation to suppress part of the code. But it suppresses everything! Unfortunately, sometimes this is too much and hides other problems. It would be nice...

LUCENE-10311: remove complex cost estimation and abstraction leakage around it

16

Cost estimation drives the API complexity out of control, we don't need it. Hopefully i've cleared up all the API damage from this explosive leak. Instead, FixedBitSet.approximateCardinality() is used for...

If it's performance sensitive enough that we should do sampling, then we should avoid integer division too. Closes #11848

### Description When looking at #11843, I noticed code of the following in several places in ExitableDirectoryReader: ``` if (calls++ % MAX_CALLS_XXX== 0) { checkAndThrow(); } ``` Unfortunately these `MAX_CALLS_XXX`...

gradle aggregate coverage report

2

### Description Currently, when running the build (e.g. `gradlew coverage`) you get a per-module report. Ideally we'd produce an aggregate report (similar to what black magic jenkins is doing: https://ci-builds.apache.org/job/Lucene/job/Lucene-Coverage-main/lastSuccessfulBuild/jacoco/...

### Your Feature Request The current pgsql check requires `username` argument, and at least it isn't obvious that it will work in the case that the server is configured to...