Hugo Wen
Hugo Wen
Hi @cvicentiu , Thank you for reviewing the pull requests and provide feedback on the benchmarking tool. I really appreciate your input. I'm traveling for meetings this week but I...
> Your benchmark shows that we need to be able to parameterize the index construction at runtime so we can expriment without recompiling. Would you be interested in tackling that...
> Updating a connection will cause a much larger write in the storage engine. We need to benchmark with longer neighbour lists (100 neighbors max for instance). Sharing some benchmark...
### Test results #### Example for a local run with `./support-files/ann-benchmark/run-local.sh`: Click to expand ``` wenhug@ud83c070d9ea75a:~/workspace/server$ ./support-files/ann-benchmark/run-local.sh Downloading ann-benchmark... Cloning into '/home/ANT.AMAZON.COM/wenhug/workspace/server/ann-workspace/ann-benchmarks'... remote: Enumerating objects: 237, done. remote: Counting objects:...
>, but they don't run in parallel. @vuvova I think might be related to the ann-benchmark framework, I'll investigate it further once I have some time from other tasks.
In addition, attach the flame graphs for reference ( generated by tool in my [PR of Support vector ANN search benchmarking](https://github.com/MariaDB/server/pull/3094) ): ### Insert:  ### Search:...
@vuvova Thank you for checking the PR. > Could you elaborate on why the stack size calculation is inaccurate? In particular, why `thd->thread_stack` is wrong? Sure. Let me know if...
smap info about the stack of `40002bd8a000-40002bdcb000` in last comment: \- *MariaDB server started with `--thread_stack='262144' (256kB)` .* ``` 40002bd8a000-40002bdcb000 rw-p 00000000 00:00 0 Size: 260 kB KernelPageSize: 4 kB...
Created Jira https://jira.mariadb.org/browse/MDEV-31151 for better tracking this issue as suggested by @grooverdan .
@dr-m Thank you for reviewing this pull request. > If it can be demonstrated that there is no performance degradation, merging this pull would seem to be the cleanest solution....