| 9 Jul 2025 |
 K900 | ACTUALLY | 17:15:29 |
 Grimmauld (any/all) | the shared memory thing? | 17:15:51 |
| K900 | Hm | 17:15:56 |
| Grimmauld (any/all) | i mean, that shouldn't be slow, at least not on the end of the closure thingy | 17:16:28 |
| K900 | What the fuck | 17:16:31 |
| K900 | It doesn't let you change the buffer size | 17:16:38 |
| K900 | On the pipe | 17:16:40 |
| K900 | OK dumb idea what if you pipe it through pv | 17:18:08 |
| K900 | With a huge buffer | 17:18:13 |
| *  raitobezarius will let you fix your rust subprocess fun | 17:21:15 |
| Grimmauld (any/all) | fair enough | 17:24:39 |
| Grimmauld (any/all) | i mean i didn't change the rust part so i was mightly confused 2.92/2.91 give such different perf. But i guess buffer changes might do that... | 17:25:25 |
| K900 | Yeah | 17:25:29 |
| K900 | I'm mildly annoyed | 17:25:37 |
| Grimmauld (any/all) | i'll see if there is a better way than just pv | 17:26:04 |
| K900 | https://doc.rust-lang.org/std/process/struct.ChildStdout.html | 17:26:22 |
| K900 | You can intorawfd it | 17:26:25 |
| K900 | You can into_raw_fd it | 17:26:29 |
| K900 | And then F_SETPIPE_SZ | 17:26:41 |
| Grimmauld (any/all) | oh no! | 17:26:51 |
| K900 | I can do the thing maybe | 17:29:01 |
| Grimmauld (any/all) | You can.
And this seems to have helped: https://git.grimmauld.de/Grimmauld/nix-closure-thingy/src/commit/833c8d5d09626e85c52a9a590c7970c4735f6f00/src/main.rs#L70
Seems to be about as slow/quick as before. Likely the bottleneck now is the sqlite lock again | 17:47:48 |
| K900 | Wait what | 17:47:59 |
| K900 | That's the wrong reader | 17:48:06 |
| K900 | Lol | 17:48:07 |
| K900 | Can you try the try branch on my fork | 17:48:21 |
| Grimmauld (any/all) | its faster now XD | 17:48:29 |
| K900 | Can you try my fork | 17:48:40 |
| Grimmauld (any/all) | i can try your version, maybe we can combine both XD | 17:48:42 |
| K900 | My ideal result is that we ~match nej | 17:51:21 |
