d
Size: a a a
2020 March 09
2020 March 10
RS
тут тема такова, что хотелось бы не аллокейтить динамический срез, который не будет выходить за пределы функции
d
var gi int
func var1(sz int) {
s := make([]int, sz)
for i := 0; i < len(s); i++ {
gi += i
s[i] = gi
}
}
ребят, не подскажете почему
s аллокейтится на heap’е и можно ли это предотвратить?код без смысла, просто для примера
не вижу кстати что б он был динамическим, ты имеешь в виду, что изначальная длина неизвестна?
d
тут тема такова, что хотелось бы не аллокейтить динамический срез, который не будет выходить за пределы функции
In cases where the initial size of a slice is known at compile time, it will begin its allocation on the stack. If this slice’s underlying storage must be expanded based on data only known at runtime, it will be allocated on the heap.RS
не вижу кстати что б он был динамическим, ты имеешь в виду, что изначальная длина неизвестна?
я имею ввиду что может расти)
RS
а в чем проблема вообще?
пытаюсь выжать из кода максимум
github.com/romshark/jsonvalidate-go
обогнал fastjson на документах больших и средних размеров, а так-же сильно на невалидных документах, но на малых по прежнему отстаю значительно. Думаю теперь ускорить
github.com/romshark/jsonvalidate-go
обогнал fastjson на документах больших и средних размеров, а так-же сильно на невалидных документах, но на малых по прежнему отстаю значительно. Думаю теперь ускорить
stack и избавиться от sync.Pool и для этого было бы неплохо stack аллокейтить в пределах функции валидации дабы избежать лишнего overhead’а. Тот редкий случай когда приходится бороться с компилятором)))C
любопытства ради — а зачем хочешь хранить в БД?
C
я игрушки прятал от лаборантов в техникуме, где учился. в году так 2006. преимущество — долго не могли найти )
C
раньше gridfs был моден )
C
а так, тут почитай
АП
любопытства ради — а зачем хочешь хранить в БД?
ну там репликация нативная :)