3 ms·

These are some really cool optimizations. It is nice that they're letting you put these in, and it's always kind of bugged me that they won't do some basic opti

by morrbo 8y ago

These are some really cool optimizations. It is nice that they're letting you put these in, and it's always kind of bugged me that they won't do some basic optimization of their util classes - like ReadDir sorting by filenames by default, removing one line of code can speed it up 800% on large directories iirc, but they won't honour the pull requests. The argument being "it's a util class, if you don't like it, don't use it.'. Whilst this is true, IMO the stdlibrary/common functions should be as quick as possible, with anything extra bolted on (within reason - sorting names being an obvious one). I wouldn't expect to have to read the actual source code in order to try and optimize, but i guess i'm wrong here ¯\_(ツ)_/¯

huntertwo 8y ago
They probably don't want to break any code that relies on that sorted output. Don't know why they would've decided on that to begin with though.
grey-area 8y ago
They take the Go 1 promise quite seriously and do try not to change existing behaviour, which is a good thing. I'm quite happy about that, because otherwise we'd see far more breaking changes, and it'd be painful to develop large apps on top of the stdlib. Perhaps in Go 2 they'd be open to changing it or moving ioutil out of the stdlib, but I'm quite sure someone somewhere depends on the ordering, and you're complaining about a 10 line function, you could just copy it out and remove the offending line: func ReadDir(dirname string) ([]os.FileInfo, error) { f, err := os.Open(dirname) if err != nil { return nil, err } list, err := f.Readdir(-1) f.Close() if err != nil { return nil, err } return list, nil } I much prefer a language and stdlib that stays stable over years, even at the cost of some nice new features/improvements - the place for code to move fast and break things (if you like that sort of thing) is much higher up the stack.
- morrbo 8y ago
  That's exactly what I did. The problem I was trying to address is you shouldn't have to expect to read into the stdlib to optimize the code. Adding a ReadDirNoSort (as suggested in the initial 2012 pull) wouldn't hurt anyone.
  - grey-area 8y ago
    Well it would expand the library surface, so now they have yet more code to maintain and they have to maintain a function with confusing and inconsistent naming forever. I think they made the right call here personally and the simplicity and stability is part of the appeal of the language.
  - Scaevolus 8y ago
    There are more optimizations than that that you could probably use if you want fast ReadDir. Golang's ReadDir reads directory entries, stats all files, and sorts the list. If all you want is the directory entries directly, try godirwalk (also much faster for walking!): https://godoc.org/github.com/karrick/godirwalk#ReadDirents https://godoc.org/github.com/karrick/godirwalk#ReadDirents

by morrbo 8y ago

huntertwo 8y ago

They probably don't want to break any code that relies on that sorted output. Don't know why they would've decided on that to begin with though.

grey-area 8y ago

They take the Go 1 promise quite seriously and do try not to change existing behaviour, which is a good thing. I'm quite happy about that, because otherwise we'd see far more breaking changes, and it'd be painful to develop large apps on top of the stdlib. Perhaps in Go 2 they'd be open to changing it or moving ioutil out of the stdlib, but I'm quite sure someone somewhere depends on the ordering, and you're complaining about a 10 line function, you could just copy it out and remove the offending line: func ReadDir(dirname string) ([]os.FileInfo, error) { f, err := os.Open(dirname) if err != nil { return nil, err } list, err := f.Readdir(-1) f.Close() if err != nil { return nil, err } return list, nil } I much prefer a language and stdlib that stays stable over years, even at the cost of some nice new features/improvements - the place for code to move fast and break things (if you like that sort of thing) is much higher up the stack.

morrbo 8y ago
That's exactly what I did. The problem I was trying to address is you shouldn't have to expect to read into the stdlib to optimize the code. Adding a ReadDirNoSort (as suggested in the initial 2012 pull) wouldn't hurt anyone.
- grey-area 8y ago
  Well it would expand the library surface, so now they have yet more code to maintain and they have to maintain a function with confusing and inconsistent naming forever. I think they made the right call here personally and the simplicity and stability is part of the appeal of the language.
- Scaevolus 8y ago
  There are more optimizations than that that you could probably use if you want fast ReadDir. Golang's ReadDir reads directory entries, stats all files, and sorts the list. If all you want is the directory entries directly, try godirwalk (also much faster for walking!): https://godoc.org/github.com/karrick/godirwalk#ReadDirents https://godoc.org/github.com/karrick/godirwalk#ReadDirents