map с указанным размером - быстрее на чтение

блин красота

надо написать функцию appendMap(map,key,value)

которая в фиксированный размером Map добавляет элемент ИЛИ создает новую копию (пусть медленно) с большим размером

которая в фиксированный размером Map добавляет элемент ИЛИ создает новую копию (пусть медленно) с большим размером

А что вы хотите получить?

Ну мап без размера будет реалоцироваться по мере добавления ключей

Что в этом странного?

Я хочу получить более быстрые на чтение map-ы за счет указания размера и не упираться в лимит за счет своей функции

да нет ничего странного. В тесте то у меня нет добавления ключей. Только поиск по существующим

в этом то вся соль. Он оптимизированней

Я должен задать этот вопрос. Никто не писал случайно такую функцию appendToMap?

А можете еще раз прислать свой тест

Я должен задать этот вопрос. Никто не писал случайно такую функцию appendToMap?

А что она должна делать?

А что она должна делать?

myMap := make(map[int]int, 3) myMap = appendMap(myMap, 1,2) myMap = appendMap(myMap, 2,5) myMap = appendMap(myMap, 9,10) // <- вот тут myMap пересоздается с размером 4 или 5 или 10 (с запасом) myMap = appendMap(myMap, 99,30) myMap = appendMap(myMap, 13,70)

А можете еще раз прислать свой тест

Только там ещё в тесте есть гугловый Btree, его можно и нужно выпилить

оставить только бенчмарки

если искать по памяти, он медленней всех

хер там, appendToMap должна знать структуру (тип) мапы, иначе её придется писать для каждого мапа заново

или как то думать про interface{}

myMap := make(map[int]int, 3) myMap = appendMap(myMap, 1,2) myMap = appendMap(myMap, 2,5) myMap = appendMap(myMap, 9,10) // <- вот тут myMap пересоздается с размером 4 или 5 или 10 (с запасом) myMap = appendMap(myMap, 99,30) myMap = appendMap(myMap, 13,70)

Делайте типизированные функции, вы всегда же знаете тип мапы, так вызывайте соответствующую.

ха, append в мапу с указанным размером без ошибок её увеличивает.

но при этом она становится медленнее=)

ну ты же указываешь не конечный размер мапы, а на сколько элементов нужно преаллоцировать памяти

у слайса тоже самое

Я хочу получить более быстрые на чтение map-ы за счет указания размера и не упираться в лимит за счет своей функции

А при чем тут чтение и указание размера?

А при чем тут чтение и указание размера?

Если у мапа предварительный размер указан большой - она работает быстрее при чтении судя по тестам

именно при чтении

Это заблуждение

Ну ты конечно можешь найти такой случай

Но в общем случае разницы нет

Тогда где я не прав? чистый бенчмарк уже ничего лишнего

на 40 процентов быстрее

Неправ в написании теста

b.ResetTimer()

Перед for n := 0; n < b.N; n++ {

Но ты прав, что-то в этом есть)

которая в фиксированный размером Map добавляет элемент ИЛИ создает новую копию (пусть медленно) с большим размером

А в го мапа так и реализована, чтение замедляет как раз избыточный размер

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

коллизия хешей? не коррелирует с избыточным размером

может там есть какая нибудь хитрая оптимизация при заранее известном размере мапы?

есть знающие люди?

Там есть хитрое говнище про oldbuckets и evacute например

При реалокации к примеру не все бакеты сразу переезжают в новое место

типа переезжают, только когда на их элементы операция read попадает и это замедляет чтение?

но совсем хардкора и кишков не будет. Оставлю это коллегам на конференциях

Хотелось бы хардкора)

типа переезжают, только когда на их элементы операция read попадает и это замедляет чтение?

В том числе

b.ResetTimer()

сделал

э

Откуда alloc?

а я хз

func BenchmarkSpeedMap(b *testing.B) { tree2 := map[int]int{} for i := 4; i < 450000; i++ { tree2[i] = i * 10 } secondids := []int{} for i := 4; i < 450000; i = i + 2 { secondids = append(secondids, i) } b.ResetTimer() for n := 0; n < b.N; n++ { result := make([]int, 0, len(secondids)) for i := 0; i <= len(secondids)-1; i++ { if res, exists := tree2[secondids[i]]; exists && res > 20 && res < 410000 { result = append(result, res) } } } }

могу переменные выбласти вглобальную область и предварительно инициировать

Сегодня вышла первая часть моего курса по Go на Coursera. Наслаждайтесь, тут многие спрашивали. https://www.coursera.org/learn/golang-webservices-1?utm_source=mipt&utm_medium=institution&utm_campaign=telegram_post_mrg

Классно, но блин, 80$ за проверку заданек...

Классно, но блин, 80$ за проверку заданек...

Попроси оплатить работодателя

😅😅 Вспоминая одну фразу - что бы просить работодателя, надо найти работодателя

Сегодня вышла первая часть моего курса по Go на Coursera. Наслаждайтесь, тут многие спрашивали. https://www.coursera.org/learn/golang-webservices-1?utm_source=mipt&utm_medium=institution&utm_campaign=telegram_post_mrg

Спасибо большое за курс. Тоже подписался. Пока вольным слушателем

а я хз

А вторая функция?

Хм

BenchmarkSpeedMap-4 100 23142364 ns/op 1802240 B/op 1 allocs/op BenchmarkSpeedMapWithSize-4 100 17854946 ns/op 1802240 B/op 1 allocs/op

Есть какое-то влияние, evacute в том числе, но небольшое. Что там еще влияет, нужно посмотреть подетальнее

Классно, но блин, 80$ за проверку заданек...

там хорошие задания. я старался сделать их такими чтобы платный сертификат был не пустым звуком, а реально давал какие-то знания

Спасибо большое за курс. Тоже подписался. Пока вольным слушателем

пожалуйста! надеюсь поможет в работе в каик-то местах

пожалуйста! надеюсь поможет в работе в каик-то местах

С учетом того, что я только устроился junior golang developer, поможет)

Есть какое-то влияние, evacute в том числе, но небольшое. Что там еще влияет, нужно посмотреть подетальнее

Домой приеду, сделаю обычный слайс который в итоге копируется в лимитный, и честный замер, а также исключить работу с массивом, чтобы чисто время слайсов замерить. Если все нормально будет, результаты в гитхабе опубликую. В целом меня возможность на 40% ускориться очень радует

Ну тут вопрос то не в ускорении, а в механике. Без понимаю "почему?!!!" это не интересно))

Пока существенную разницу видно только в этом

Почему я уже задавал

2.25s 35.83% 35.83% 2.40s 38.22% runtime.mapaccess2_fast64 /usr/local/Cellar/go/1.9.2/libexec/src/runtime/hashmap_fast.go 2.23s 35.51% 71.34% 2.23s 35.51% runtime.mapaccess2_fast64 /usr/local/Cellar/go/1.9.2/libexec/src/runtime/hashmap.go

vs

3.28s 69.05% 69.05% 3.62s 76.21% runtime.mapaccess2_fast64 /usr/local/Cellar/go/1.9.2/libexec/src/runtime/hashmap_fast.go

А как аллоки убрал до одного?

b.ResetTimer() for n := 0; n < b.N; n++ {

Или там можно как и время в ноль сбросить?

В обеих функциях

Таймер аллоки тоже сбрасывает?

Таймер сбрасывает замеры

Отлично

Надо под линуксом ещё померить