Hugo Wen

Results 12 comments of 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: ![perf data inserting 2024-03-26-15-26-48](https://github.com/MariaDB/server/assets/46255328/b76e667c-2c6f-437c-9bc5-3298b0eb96cc) ### 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....