Вот это уровень)

сделай структуру на 8 байт

все равно не спасёт

Насколько я помню copy может память поджирать

Там есть какой-то ньюанс но вот не помню какой

счас попробую просто по индексам приравнять. мне не сложно

народ, посоветуйте шонить по го паттернам

я за него только взялся, синтакис вроде несложный

All keys

Capacity установлен ?

Насколько я помню copy может память поджирать

внезапно полегчало. стало 500 вместо 650

но все равно много

А не , в коде у тебя динамика

Он автоматом запасает память при аппенде

+ 1/3 сверху

Или что-то вроде того

Denis кстати прав

Попробуй с конечным капасити

И без аппнда

А по индексу

Вставлять значения

да. капасити сильно больше length

+ 1/3 сверху

вообще будет ресайз до cap == следующее простое число

Там у них в коде формула интересная

проблема в том что заранее сложно прикинуть, но счас попробую захардкодить для теста

@Holoview Привет! Советовать не могу, но есть такая ссылка https://github.com/AlexanderGrom/go-patterns

@Holoview Привет! Советовать не могу, но есть такая ссылка https://github.com/AlexanderGrom/go-patterns

Благодарствую! =)

@Holoview Принято :)

Попробуй с конечным капасити

да. так получился оверхед ровно в 2 раза. - осталось понять откуда он.

Он автоматом запасает память при аппенде

Можно исходники гошки глянуть

Так понятнее станет

Запасает чтобы каждый раз не просить систему за память

это я понял уже.

факт, о котором не задумываешься, пока тебе не скажут: а ведь в коде определения append() используется append()

Скинь сэмпл

Может там подвох:)

факт, о котором не задумываешься, пока тебе не скажут: а ведь в коде определения append() используется append()

Слушай, как великий специалист по коду языка скажи насколько слайсы медленнее массивов?

Слушай, как великий специалист по коду языка скажи насколько слайсы медленнее массивов?

я себя так не называл, но спасибо) на каких задачах?

На задаче буфера в памяти на 1 гбайт. Что то типа кольцевого буфера

ну, ты же ресайзить его, получается, не будешь. а значит он должен быть практически такой же.

Почему не буду? Если на массивах то делать придется буфера и управлять ими, а если сплайсы - оно типо само

ну, если будешь ресайзить — то на время ресайза будет просадка.

https://github.com/golang/go/blob/master/src/runtime/slice.go#L82

да. так получился оверхед ровно в 2 раза. - осталось понять откуда он.

всем пофиг конечно но оверхед взялся на том как я эти данные читал из файла.

переменная чтоль размером была не байт?

ну, если будешь ресайзить — то на время ресайза будет просадка.

Это я понимаю как раз!

Это я понимаю как раз!

ну. а в остальном практически то на то и будет.

Был глупый вопрос - надо делать как проще, потом запускать профайл

Давай лучше спрошу твой любимый вопрос

Если делать многопоточность - наколько будет проседать производительность с потокобезопасными структурами - map, slise, arrays ?

а смотря на каком уровне потокобезопасность обеспечишь

если рантайм поправишь — можно сделать без проседаний

все стандартно

все стандартно

что ты под этим подразумеваешь?

Где править?

что ты под этим подразумеваешь?

стандартную библиотеку, стандартные паттерны

Где править?

по-своему для каждого типа.

Это совместимо с обычным го?

стандартную библиотеку, стандартные паттерны

если ты о структуре с rw lockом, то просадка будет серьезной

если ты о структуре с rw lockом, то просадка будет серьезной

Один поток пишет - много читают

Это совместимо с обычным го?

такие правки? ну, у меня всё после таких правок работает. а вообще зависит от того, кто эти правки делает.

Боже

Зачем вам локи ?

Ну кольцо же

ты упустил изменение темы

Это совместимо с обычным го?

Смотри, он тебя совратит

ERROR: S client not available

Мне интересен патч в оф го репу

Они их уже принимают

Смотри, он тебя совратит

да @pifagorych вроде как был уже у нас в чате

Мне интересен патч в оф го репу

не будет такого никогда

https://github.com/golang/go/issues/17043

Ответ конечно интересный

Жду форк)

Ответ конечно интересный

с этого вообще Goodlang и начался, по большому счету.

вернее — тогда я стал планировать вот это всё

We will not be supporting concurrent write+write or read+write map updates in the standard library, in any package. We will not support them in our house, We will not support them with your mouse. We will not support them here or there, We will not support them anywhere. We kinda support them, in an atomic.Value box, We will not support them in Firefox. We will not support them in a car, ... (please, no unsafe in automotive systems..)

Я вдохновлен!

Реп

There anywhere

Box Firefox

Норм же

Реп

я это всегда читал с выражением, как сверх серьезный стих

Может кто на бит положить?

норм ответ, посмеялся когда встал его )

Может кто на бит положить?

я вообще музыкант.

Я тогда танцор

Ну в смысле серьезно ?

А я пиво люблю. Могу прийти на ваше выступление и покричать :)

я вообще музыкант.

я на днях упоролся и записал это в опыт работы в своё резюме

Так на чем мы остановились? Чтение безопасно для всех структур? Что то типа этого написано было в issue.

Так на чем мы остановились? Чтение безопасно для всех структур? Что то типа этого написано было в issue.

не-а. в мапах, например, во время записи чтение вызовет панику

для этого и приходится rwlock таскать

это и раздражает в Go

да нормальный tradeoff )

не нормальный

Кирилл, эта проблема только для мапов или всех структур в Го?

по структурам не помню. вроде как со структурами такой фигни нет.

это и раздражает в Go

первая версия явы вышла с полностью сихронизированными (замутексованными) структурами данных. HashTable, Array, вот это вот все уже к версии 1.2 им пришлось сделать параллельные структуры, без мутексов. HashMap, ArrayList, вот это вот все. потому. что программер все же лучше знает, когда надо делать lock, а когда сойдет и так.