“Clean” Code, Horrible Performance

Re:“Clean” Code, Horrible Performance by vore on Tuesday February 28, 2023 @04:23AM (#34967348)

Have you never used C++ iostreams? Or the Python file abstraction? Or Rust std::io::Read/std::io::Write? Or Node.js streams? Or DOM Web Streams? Or Ruby files? Or Haskell conduits? Or hell, fopencookie/funopen in C?

The abstraction is super common and allows you to connect streams to each other without worrying about the underlying mechanism, which 99% of the time I don't really think you want to worry about unless you're sure it's a performance overhead. And that's great, because I surely don't want to write specializations by hand for all the different combinations of streams I need to use if I don't have to.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by anonymoushn on Tuesday February 28, 2023 @04:31AM (#34967400)

I've used open(2) and the io_uring openat :)

I use generic readers and writers every day, but they don't have any runtime dispatch. The question was "Why would you do anything except vtables and runtime dispatch?" One answer is that my code that uses generic readers and writers and gets monomorphized gets to also be generic over async-ness.

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by vore on Tuesday February 28, 2023 @04:33AM (#34967415)

There you go, actually: you can have your clean code cake and eat it too if you have the right language abstractions (like parametric polymorphism).

[ Parent | on HN ]

Re:“Clean” Code, Horrible Performance by saagarjha on Tuesday February 28, 2023 @04:33AM (#34967411)

Except in the kernel, of course.

[ Parent | on HN ]