7 ms·
> What I would like is for my image decoding function to notice that the io.Reader it has been given is in fact a bytes.Reader so we can skip the copy. What a
by 38 1y ago
> What I would like is for my image decoding function to notice that the io.Reader it has been given is in fact a bytes.Reader so we can skip the copy.
What a terrible idea. If you want bytes.reader, then use that in the function signature, or better yet just a byte slice. It should have been a red flag when your solution involves the unsafe package
- Groxx 1y agoI think you kinda missed the point. The point is that trying to make a user-friendly API with the familiar, highly composable, and extremely common io.Reader that everything (including Go's stdlib) encourages you to use ends up putting you in this unfortunate design corner if you also care about performance. It's frustration about getting close to a good API, but not having any reasonable way to close the final gap, forcing you do you to go stuff like you mentioned: have multiple near-identical APIs for performance, and needing your users to understand and use them correctly to get a good result.
- XorNot 1y agoThe benefit seems fictional though. When is the user going to have all the bytes in memory but only have an io.Reader? Probably never. If I have a reader it's because the bytes are coming from something which itself does not make that promise. Like the most common application would be an os.File. If I do have all the bytes in memory, then I have a []byte array, know I have it, and can use the []byte interface you must've implemented internally to use this speed up.
- Groxx 1y agoI think you kinda missed the point. The point is that trying to make a user-friendly API with the familiar, highly composable, and extremely common io.Reader that everything (including Go's stdlib) encourages you to use ends up putting you in this unfortunate design corner if you also care about performance. It's frustration about getting close to a good API, but not having any reasonable way to close the final gap, forcing you do you to [do] stuff like you mentioned: have multiple near-identical APIs for performance, and needing your users to understand and use them correctly to get a good result.
- porridgeraisin 1y agoBut if you have two modes of operation: - Reading in memory data - Reading from a stream Then whats wrong with having two different APIs to use each mode? Instead of you doing a if (detect in memory) in your code, it's just two different functions.
- Groxx 1y agoNothing. Or next to nothing at worst. It would just be nice if it could automatically do the best thing.