История изменений
Исправление lbvf50txt, (текущая версия) :
Кроме дизлайков и цепляния к словам, я что-то не наблюдаю у вас конструктивной критики по поводу единичного выделения буфера для сокращения нагрузки на сборщик мусора.
LamerOk, вы наставили дизлайков (тут, тут), т.е. вы утверждаете, что выделать отдельную память для каждого чтения это более оптимально чем выделить память единожды?
Бенчмарк показывает обратное, использование одного буфера повышает скорость работы на порядок.
Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию. Объясите почему интерфейс io.Reader
сконструирован именно так как он сконсртурирован. Объясните почему *os.File
и *gzip.Reader
удовлетворяют интерфейсу io.Reader
, какой патерн используют в Golang для связывания всех этих разноплановых типов в единый работающих механизм.
Исправление lbvf50txt, :
Кроме дизлайков и цепляния к словам, я что-то не наблюдаю у вас конструктивной критики по поводу единичного выделения буфера для сокращения нагрузки на сборщик мусора.
LamerOk, вы наставили дизлайков (еще,eще), т.е. вы утверждаете, что выделать отдельную память для каждого чтения это более оптимально чем выделить память единожды?
Бенчмарк показывает обратное, использование одного буфера повышает скорость работы на порядок.
Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию. Объясите почему интерфейс io.Reader
сконструирован именно так как он сконсртурирован. Объясните почему *os.File
и *gzip.Reader
удовлетворяют интерфейсу io.Reader
, какой патерн используют в Golang для связывания всех этих разноплановых типов в единый работающих механизм.
Исправление lbvf50txt, :
Кроме дизлайков и цепляния к словам, я что-то не наблюдаю у вас конструктивной критики по поводу единичного выделения буфера для сокращения нагрузки на сборщик мусора.
LamerOk, вы наставили дизлайков (еще), т.е. вы утверждаете, что выделать отдельную память для каждого чтения это более оптимально чем выделить память единожды?
Бенчмарк показывает обратное, использование одного буфера повышает скорость работы на порядок.
Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию. Объясите почему интерфейс io.Reader
сконструирован именно так как он сконсртурирован. Объясните почему *os.File
и *gzip.Reader
удовлетворяют интерфейсу io.Reader
, какой патерн используют в Golang для связывания всех этих разноплановых типов в единый работающих механизм.
Исправление lbvf50txt, :
Кроме дизлайков и цепляния к словам, я что-то не наблюдаю у вас конструктивной критики по поводу единичного выделения буфера для сокращения нагрузки на сборщик мусора.
LamerOk, вы наставили дизлайков (еще), т.е. вы утверждаете, что выделать отдельную память для каждого чтения это более оптимально чем выделить память единожды?
Бенчмарк показывает обратное, использование одного буфера повышает скорость работы на порядок.
Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию. Объясите почему интерфейс io.Reader
сконструирован именно так как он сконсртурирован. Объясните почему *os.File
и *gzip.Reader
удовлетворяют интерфейсу io.Reader
, какой патерн используют в Golang для связывания всех этих разноплановых типов в единый работающих механизм.
Исходная версия lbvf50txt, :
Кроме дизлайков и цепляния к словам, я что-то не наблюдаю у вас конструктивной критики по поводу единичного выделения буфера для сокращения нагрузки на сборщик мусора.
LamerOk, вы наставили дизлайков (еще), т.е. вы утверждаете, что выделать отдельную память для каждого чтения это более оптимально чем выделить память единожды?
Бенчмарк показывает обратное, использование одного буфера повышает скорость работы на порядок.
Давайте, напишите развёрнутый технический комментарий, доказывающий вашу позицию. Объясите почему интерфейс io.Reader
сконструирован именно так как он сконсртурирован. Объясните почему *os.File
и *gzip.Reader
удовлетворяют интерфейсу io.Reader
, какой патерн используют в Golang для связывания всех этих разноплановых типов в единый работающих механизм.