goh-chunlin

Really like the simplicity philosophy here.

Great to see `--dry-run` on the roadmap! One thing I'd love to see is if `proc kill` could show a confirmation table of exactly which PIDs would be targeted before executing, similar to how `terraform plan` works.

Glad that helped!

Perhaps you can start with comparing 1,000 individual INSERTs (each with its own COMMIT) vs. 1,000 INSERTs wrapped in a single BEGIN/COMMIT block. This test is particularly interesting for comparing different RDBMS because it reveals how each engine balances data durability (ACID) against performance. You will likely find that some DB have a much higher tax on commits than others, which is a key factor in choosing a DB for a specific use case.

Since you are in C, please make sure to use prepared statements. If you send raw SQL strings, you are partially benchmarking the string parser of the DB rather than the actual data manipulation. Also, remember to "warm up" the DB with a few hundred runs before you start the timer, otherwise, the results will be skewed by the initial disk-to-memory cache loading.

May I know how latency will be handled? If a page takes 5 seconds to load, does the vision model keep 'guessing' while the screen is blank, or is it smart enough to wait for a specific visual state?

clock_t measures CPU time (the time the processor spent on your specific process). In database benchmarking, the CPU is often idling while waiting for Disk I/O or Network latency.

If clock_t is used, normally results will show the database is "blazing fast" because it does not count the time spent waiting for the hard drive to actually save the data.

You may need to look into CLOCK_MONOTONIC. clock_gettime(CLOCK_MONOTONIC, ...) will measure "Wall Clock" time.

AutoAds focuses heavily on 'SaaS products', but most SaaS value lives behind a login wall. Does it handle authentication? Or is this strictly for public-facing marketing landing pages?

This looks clean. I appreciate the pkg decoupling.

Regarding the server mode (swatchify serve): Does the decoding step have a hard memory limit or dimension cap? Since image.Decode expands compressed files into full bitmaps, I am wondering if a large resolution upload (like a 4k print asset) could OOM-kill the container before the downscaler kicks in.