Joshua BarrettoI made project-wide search in my text editor asynchronous so results stream in from worker threads without blocking the main thread. However, searching is so fast that it finishes before the next frame renders, even on the largest project I work on, so it was entirely wasted effort.
princess pancake 
@jsbarretto it's not really a waste when the async I/O is likely the reason the frame was rendered on time
@natty The I/O isn't itself meaningly faster (workers still block on file access, so it's only asynchronous from the perspective of the main threads). But I was hoping to see the number of results tick up in a more satisfying way instead of appearing instantly. I realise that this is a silly thing to be sad about though
gaytabase
@jsbarretto @natty a bit relevant to me this week as i build a new foundation for async i/o.
in C.
@jsbarretto @natty (nightmare of course is not even cross platform, it's the bit where i don't have any cool facilities and have to using blocking i/o and a threadpool)
@jsbarretto @natty huh? i mean when there are no async file i/o apis. so the most obvious thing you could call 'in flight' is literally one op per OS thread.
@jsbarretto @natty oh, i haven't decided what to do yet. like your example, is it worth spinning up a new thread for what could be a small op?
OTOH, if we don't do that, we have to have elaborate thread management
@jsbarretto @natty i know. but actually i think it's funnier that tokio starts tens of threads of my machine even if i do no i/o than that it does this.
also the docs said something about a 1000 thread default limit so shrug
@jsbarretto @natty i've no idea. i am allergic to tokio and its build times so i try not to keep up with them.
ARGVMI~1.PIFIsn't that pretty much how non-blocking IO works? The syscall returns immediately if the bytes are already in memory, otherwise EAGAIN and wait for a notification via epoll.
But it doesn't work for files, for some reason…
@argv_minus_one @dysfun @natty Well, yes and no. There's no particular reason to go to the effort of spinning up a new software thread for each I/O task. Take a look at Linux's io_uring API, it demonstrates how async IO can be made extremely lightweight, even with a huge number of tasks in-flight.
d@nny disc@ mc²@jsbarretto @natty local block i/o is not likely to receive significant benefit from non-blocking access
@jsbarretto @natty context switching can be pretty harmful and outside of extremely specialized interfaces there's no conception i've found that effectively asynchronizes this process
@hipsterelectron That's broadly what I'm finding, although I wonder whether very small files might flip that calculus a little. Probably depends on how clever the filesystem/vfs stack is about prefetching stuff from disk.
@jsbarretto vfs.......long have i sought for the vfs. that's something we can abstract. i do like your thought on small files. one unrelated/related thing it reminds me of is prefix codes for compressed data
DaforLynx VGM@jsbarretto this is so funny and real, thank you
Soso@jsbarretto try it on a large project with a cold cache. Then it will take some time. Helix has that and it's very useful. On large projects (or even directories), the results come slowly and it's really helpful for it not to freeze.
Also you'll love it the day you start working on a slow network filesystem like sshfs.
@sgued The only way I can tell that it's working has been to manually tell Linux to drop its fs cache!
Sijmen 🧑💻@jsbarretto one place where I did have noticeable search times was when working with pkgsrc on a HDD