PRD до нас доходит редко. Нам чаще всего ставят задачи уже эти вот самые проджект менеджеры, описанные в статье uyga. Это связано с тем, что наш результат не является тем, что видит пользователь. Наш результат используется другими программистами, чтобы сделать то, что видит пользователь.
Но с продактами общаться нам тоже приходится. В основном когда изменение связано с какими-то внутренними вещами, алгоритмами, поведением, которое не требует изменения со стороны «клиента».
Не вижу в этом ничего плохого. Мы же делаем продукт все вместе, а не сидим и слепо пишем код по разжеванному описанию.
— Довольно странное решение, на мой взгляд, оставаться на Perl, если уж появилась возможность уйти от Мрор. Почему? Ведь большинство людей, услышав Perl, сразу же думают о вымерших динозаврах. Вы видите будущее у этого языка?
— Сейчас у большинства крупных игроков есть свои «облака» для бизнеса. Но очень сложно выбрать, понять какой из облаков лучше. Я с ходу не нашел у вас на сайте https://biz.mail.ru/ сравнения с другими облаками. Планируется ли такое сравнение сделать? Ну и есть ли\будут ли какие-то средства для переноса данных из других облаков?
— Мне, как частному лицу, тоже очень хочется иметь почту на своем домене (на самом деле уже есть), но у вас везде «бизнес», «бизнес». Могу ли я как частное лицо платить и пользоваться всеми этими фичами? Не будет ли каких-то заморочек?
— Что за БД под древовидные данные? Есть где-то более подробная информация?
— Планируется ли сделать клиенты под ваше облачное хранилище для операционной системы что стоит на Synology NAS-ах? Большинство из популярных там уже есть.
Я попробовал собрать один из наших proto стандартным компилятором. Если собрать не указывая proto3, то ничего не поменялось. Указатели.
Если сделать синтакс прото3, то надо в proto много чего поправить (убрать все optional, required, все enum начинаются с 0, нет дефолтных значений) и получается без указателей, действительно.
Но я в апи не вижу как понять задано поле или нет. Только сравнивать с нулевым значением?
Это очень интересно. Надо посмотреть как они понимают задано поле или нет. Там теоретически вариантов несколько. Например, использовать has_ поля булевые, как в protobuf-c или битовые поля.
Я писал всегда и все в Vim. Некоторое время пробовал VS Code. Он мне нравится, но там нет просмотра тегов. В остальном он классный. Ну и последний месяц я активно пробую Gogland. Gogland мощный и вкусный, но я пока не привык к таким монструозным IDE и учусь новым вещам очень медленно. Скорее всего я так и продолжу использовать Vim и Gogland.
Привет. Я не специалист в компиляторах, но предполагаю что это возможно. Просто Go-шный escape анализатор этого не умеет пока.
Я взял и упростил твой код до такого, когда никаких строк нет. И даже return value нет. Только вызов функции интерфейса.
$ cat lala_test.go
package lala
import (
"testing"
)
type Fooer interface {
Foo()
}
func GetString(s Fooer) {
s.Foo()
}
type Text struct {
val string
pad [24]byte
}
func (t Text) Foo() {
}
func BenchmarkGetString(b *testing.B) {
for i := 0; i < b.N; i++ {
t := Text{val: "hello"} // Moved to heap, 24 bytes for pad and 8 bytes for string.
GetString(&t) // Allocation for Stringer 8 + 8 bytes.
}
}
Если убрать вызов
s.Foo()
из
func GetString(s Fooer)
то аллокации не будет. Предполагаю что любой такой вызов по интерфейсу приведет к escape, т.к. анализатор не знает что именно произойдет в вызываемой функции.
P.S. Чтобы получить больше подробностей, можно передать -m -m (два раза).
PRD до нас доходит редко. Нам чаще всего ставят задачи уже эти вот самые проджект менеджеры, описанные в статье uyga. Это связано с тем, что наш результат не является тем, что видит пользователь. Наш результат используется другими программистами, чтобы сделать то, что видит пользователь.
Но с продактами общаться нам тоже приходится. В основном когда изменение связано с какими-то внутренними вещами, алгоритмами, поведением, которое не требует изменения со стороны «клиента».
Не вижу в этом ничего плохого. Мы же делаем продукт все вместе, а не сидим и слепо пишем код по разжеванному описанию.
— Довольно странное решение, на мой взгляд, оставаться на Perl, если уж появилась возможность уйти от Мрор. Почему? Ведь большинство людей, услышав Perl, сразу же думают о вымерших динозаврах. Вы видите будущее у этого языка?
— Сейчас у большинства крупных игроков есть свои «облака» для бизнеса. Но очень сложно выбрать, понять какой из облаков лучше. Я с ходу не нашел у вас на сайте https://biz.mail.ru/ сравнения с другими облаками. Планируется ли такое сравнение сделать? Ну и есть ли\будут ли какие-то средства для переноса данных из других облаков?
— Мне, как частному лицу, тоже очень хочется иметь почту на своем домене (на самом деле уже есть), но у вас везде «бизнес», «бизнес». Могу ли я как частное лицо платить и пользоваться всеми этими фичами? Не будет ли каких-то заморочек?
— Что за БД под древовидные данные? Есть где-то более подробная информация?
— Планируется ли сделать клиенты под ваше облачное хранилище для операционной системы что стоит на Synology NAS-ах? Большинство из популярных там уже есть.
Если сделать синтакс прото3, то надо в proto много чего поправить (убрать все optional, required, все enum начинаются с 0, нет дефолтных значений) и получается без указателей, действительно.
Но я в апи не вижу как понять задано поле или нет. Только сравнивать с нулевым значением?
https://golang.org/pkg/runtime/
Я взял и упростил твой код до такого, когда никаких строк нет. И даже return value нет. Только вызов функции интерфейса.
Если убрать вызов
из
то аллокации не будет. Предполагаю что любой такой вызов по интерфейсу приведет к escape, т.к. анализатор не знает что именно произойдет в вызываемой функции.
P.S. Чтобы получить больше подробностей, можно передать -m -m (два раза).
Чуть-чуть похожий тикет есть https://github.com/golang/go/issues/17332. Но я бы порекомендовал создать еще один с этим конкретным тест кейсом.
А искать по коду нужно по строке «receiver in indirect call»:
В коде "запускатора" бенчмарка можно эту цифру изменить.
dense -> judy -> spp
Результаты есть в репозитории. Я не стал рисовать эти графики и добавлять в статью, т.к. скорость добавления нам в данном случае не критична.