Обширная тема, и я давно хочу написать по ней пост, но если вкратце, то очень хорошо плохой дизайн языка виден на примере функций GetEnv и LookUpEnv. Они обе предназначены для получения значений переменных среды, но GetEnv возвращает строку, которая будет пустой в случае отсутствия такой переменной, а LookUpEnv возвращает кортеж из строкового значения и булевого флага, сигнализирующего о том, найдено ли значение. Зачем же понадобились две функции для выполнения одной и той же задачи? А понадобились они потому, что обработка ошибок в стиле Go слишком многословна. Поэтому, в дополнение к идиоматичной, но неудобной LookUpEnv сделали уродца GetEnv, который возвращает валидное значение в случае ошибки. Можно было бы назвать это частным случаем, но такой подход проистекает из общего плохого дизайна языка. Правильным решением этой конкретной задачи были бы опции, но опций в Go нет и не будет, потому что нет дженериков. Та же история и с типами Result/Try. И из-за этого обработка ошибок в Go обладает целым списком фатальных неодстатков:

• Возможность обратиться к полю кортежа, которое неопределено. Возвращать кортеж для сигнализации об ошибке — несусветная глупость, потому что в нём всегда валидно только одно поле, а возвращаются сразу два
• Проигнорировать наличие ошибки проще, чем проверить
• Необходимость наличия в языке такой пакости, как нулевые указатели для маркировки неопределённого значения
• Общая многословность обработки ошибок.

Самое полезное в треде, я только сейчас узнал об Electric Fence.

О, ты посмотрелся в зеркало? Отлично, это первый шаг к правильным выводам. Только не останавливайся.

А тебя никто не заставляет ограничиваться чистым C.

А с учётом того, что тестируемый код на C++, вообще непонятно, откуда и зачем ты взял C.

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

Теперь тебе осталось показать, что кто-то полагается на «конкретные настройки overcommit» при определении скорости.

Докажи. Более традиционной структурой, которая даёт эффективный поиск и использует такой же «overcommit»

структурой, которая использует такой же «overcommit»

структурой, которая использует «overcommit»

Из этого я и делаю вывод, что проблема std::map или в мелких аллокациях и недружественности к кэшу, или собственно алгоритме с недостаточно «плоским» деревом, или в обоих.

Что случилось с QNX

Воистину, хуже идиота только агрессивный идиот, упорствующий в своём идиотизме.

Ну тогда тем более сам должен был отловить, или вместо макроса использовать шаблонную функцию.

Чтобы доказать, что оверкоммит тут хоть как-то при чём...

показать действительно аналогичную реализацию со сравнимой скоростью, которая бы что-то полезное делала, а не просто заливала память константами. Ты даже не попытался это сделать.

Докажи. Более традиционной структурой, которая даёт эффективный поиск и использует такой же «overcommit».

Чувак! Не тупи ты так яросно, ну!