Hey, the figures in readme sounds interesting, but any claims about figures requires the proofs to make reader consider the figures while decision making.
Let's add the benchmark and publish exact results in readme.
As a potential user of rx I want to know the bootstrap time and to see some measurements against a real use cases.
I propose to measure
- Initialization time. That is a time needed to convert a file data into a JavaScript object that is ready to use synchronously. It would be nice to have examples with small files (a kilobytes), a middle size files (a few megabytes) and a large files (a few hundred of megabytes).
- A RAM consumption
- Access time to an object properties
Also i've just looked at bench.ts, this line looks confusing
|
const buf = new Uint8Array(readFileSync("/Users/tim/Code/rex/large-sample.rexc")); |
It seems the script trying to read the file from a root. I have no user tim on my macbook, so probably the bench will not work for me.
Make sure the benchmark are reproducible. Such slips makes people think the project have been vibe coded by a developer who don't know how thinks does work.
That is very dangerous for credibility, because in case the developer don't know how paths in OS does work, the code may contains the dangerous instructions or even backdoors. Actually because of such slips the DuckDB project is lost all credibility after successfull phishing attack on one of its maintainers.
Hey, the figures in readme sounds interesting, but any claims about figures requires the proofs to make reader consider the figures while decision making.
Let's add the benchmark and publish exact results in readme.
As a potential user of rx I want to know the bootstrap time and to see some measurements against a real use cases.
I propose to measure
Also i've just looked at
bench.ts, this line looks confusingrx/bench.ts
Line 13 in a950102
It seems the script trying to read the file from a root. I have no user
timon my macbook, so probably the bench will not work for me.Make sure the benchmark are reproducible. Such slips makes people think the project have been vibe coded by a developer who don't know how thinks does work.
That is very dangerous for credibility, because in case the developer don't know how paths in OS does work, the code may contains the dangerous instructions or even backdoors. Actually because of such slips the DuckDB project is lost all credibility after successfull phishing attack on one of its maintainers.