Nc_Soft: Надо выбирать то, что лучше подходит под конкретную ситуацию. И, если мне разово надо спарсить пару страниц, или эта операция выполняется сравнительно не часто, то нет смысла заморачиваться на gzip'ы (особенно, если на текущей платформе это дело не такое тривиальное как в node), когда достаточно добавить определенный заголовок к запросу.
J. Bravo: Глянул в спеку, действительно: "If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding.". Тогда попробуйте указать заголовок Accept-Encoding: identity . Тут уж Вам по rfc не должны отказывать.
J. Bravo, для простоты можно еще удостовериться, что в заголовках не передается Accept-Encoding параметр. Сервер тогда не должен применять gzip и будет отдавать нормальную страницу.
andreyvlru: вообще должен, так как на одном большом файле скорости передачи есть куда "разогнаться", в отличии от кучи мелких файлов. Другой вопрос, что требуется дополнительное место, что не всегда вариант. Ну и я не уверен в том, насколько лучше станет.
Армянское Радио: можно написать тесты и для синхронизации, можно и для проверки на утечку ресурсов. Было бы желание/фантазия/время/ресурсы. Также не катит вариант, когда проект уже есть и архитектура у него плохо тестируемая и переписывать ради тестов проект никто не будет, или, возможно, платформа как-то ограничивает.
Написание тестов не отменяет детальное логгирование и все вышеуказанные советы, разумеется. Не панацея, не серебренная пуля. Но если они есть, и пишутся, и поддерживаются, то это +100500 к предсказуемости, уверенности в коде и painless дебаге, так как многие ситуации гораздо легче смоделировать.
uvelichitel, neolink
Сделал небольшой бенчмарк play.golang.org/p/LUD4idmK0D .
Онлайн не работает, платформа режет. Скопируйте в локальный файл и через go run.
У меня стандартный вариант через < 0 работает чуть-чуть быстрее. Платформа darwin/amd64.
Benchmark of AbsStd():
2000000000 0.68 ns/op 0 B/op 0 allocs/op
Benchmark of AbsMagic():
2000000000 0.70 ns/op 0 B/op 0 allocs/op
Отрыв варьируется от 0 до 0.03 ns/op.
SilentFl, Виталий Яковенко, все понял, благодарю за пояснение. Я как-то банально не заметил close() в примерах выше, потому мой мир и пошатнулся. Теперь картинка встала на место.
SilentFl: кстати, странно...чего-то я перестал понимать. Разве главная горутина не должна заблокироваться, когда вычитает все значения?
В спецификации четко написано:
If the capacity is zero or absent, the channel is unbuffered and communication succeeds only when both a sender and receiver are ready. Otherwise, the channel is buffered and communication succeeds without blocking if the buffer is not full (sends) or not empty (receives).
Виталий Яковенко: Что-то я погорячился, каюсь. С sync.Once все в порядке, если операцию запроса к бэкенду не пихать sync.Once, а оставить там только отправку в канал. Тем не менее, схема замечательно реализуется без sync тоже.