Там, на самом деле, отсутствуют и другие элементы. Просто выводится содержимое только одного бакета. А во втором выводе, после роста мапы, бакетов становится уже несколько. Собственно, распределение элементов по бакетам после роста мапы - процесс случайный и просто так получилось что новый элемент попал в новый бакет, который просто не вывели. Если позапускать код несколько раз - то можно поймать его и в этом бакете.
Повлияет, конечно. На саму асинхронную обработку, так или иначе, действительно расходуются ресурсы. Но я бы не сказал что это проблема асинхронной обработки, это скорее проблема выбора инструмента и(или) подхода к разработке. Если есть задача в которой необходимо утилизировать 100% CPU, ну, кажется стоит обратить внимание на более низкоуровневые языки. И самостоятельно управлять потоками, памятью и прочим.
Асинхронная обработка в го, скорее (но не только), позволяет, так сказать, выполнять операции которые можно не делать прямо сейчас в отложенном режиме.
Да, согласен, немного не корректно получилось. Наверное, стоило явно писать "эвакуация данных" когда это подразумевалось, а то местами выглядит будто эвакуация мапы.
По росту - да, в go он асинхронный. Из-за этого могут возникать ситуации когда при попытке доступа к данным часть бакетов уже переехала, а часть нет. Но, благодаря этому не происходит просадок во время роста большой мапы.
Спасибо, поправил
Там, на самом деле, отсутствуют и другие элементы. Просто выводится содержимое только одного бакета. А во втором выводе, после роста мапы, бакетов становится уже несколько. Собственно, распределение элементов по бакетам после роста мапы - процесс случайный и просто так получилось что новый элемент попал в новый бакет, который просто не вывели. Если позапускать код несколько раз - то можно поймать его и в этом бакете.
О, спасибо, совсем забыл добавить, даже в самом тексте ведь обещал. Собственно, добавил в статью код ф-ции и небольшое описание к нему.
Согласен, добавил небольшой блок с уточнением.
Повлияет, конечно. На саму асинхронную обработку, так или иначе, действительно расходуются ресурсы. Но я бы не сказал что это проблема асинхронной обработки, это скорее проблема выбора инструмента и(или) подхода к разработке. Если есть задача в которой необходимо утилизировать 100% CPU, ну, кажется стоит обратить внимание на более низкоуровневые языки. И самостоятельно управлять потоками, памятью и прочим.
Асинхронная обработка в го, скорее (но не только), позволяет, так сказать, выполнять операции которые можно не делать прямо сейчас в отложенном режиме.
Да, согласен, немного не корректно получилось. Наверное, стоило явно писать "эвакуация данных" когда это подразумевалось, а то местами выглядит будто эвакуация мапы.
По росту - да, в go он асинхронный. Из-за этого могут возникать ситуации когда при попытке доступа к данным часть бакетов уже переехала, а часть нет. Но, благодаря этому не происходит просадок во время роста большой мапы.