Comments 25
Зачем там вообще hashtable? 🙄
Это ещё что, видел использование HashTable для хранения всего двух значений - баланса двух игровых валют в одной мобильной игре.
Это что горячий кусок кода какой-то? В чем проблема
Это вопрос забивания гвоздей микроскопом. Да, пожалуй, можно, если вломы идти до молотка, а микроскопов у тебя -- до той матери...
```python3
import timeit
d = {'EUR': 1, 'GBP': 2}
l = [1, 2] # EUR, GBP
i = 0
def test_dict():
currency = 'EUR' if i % 2 == 0 else 'GBP'
d[currency] += 1
def test_list():
currency_pos = 0 if i % 2 == 0 else 1
l[currency_pos] += 1
t = timeit.timeit(test_dict, number=1000000)
i = 0
t2 = timeit.timeit(test_list, number=1000000)
print(t, t2)
```
0.16804020782001317 0.14995945803821087
Разница незначительная, зато явно обозначено как получить доступ к какой валюте. Писал бы в словарь, найдутся более интересные места для оптимизации чем такая тривиальщина.
В других языках конечно может быть все иначе
12% разница. Курочка она по зёрнышку -- и это медленный язык. В сях еще больше.
Но главная ошибка, в логике, это использование итерации по контейнеру без гарантии порядка и ожидание порядка.
12% в коде который работает раз в миллион лет по сравнению с остальной логикой программы стоит того, чтобы потерять читаемость программы, содержать контракт на порядок валют и заморачиваться с этим...
Оптимизируйте горячий код, не занимайтесь ерундой
во-1х, речь шла не про порядок валют а про порядок компонент при чтении картинок. во-2х есть разница между оптимизацией и корректностью.
Можно жертвовать производительностью в угоду читаемости, нельзя жертвовать корректностью в угоду читаемости.
Вы в треде про валюты в мобильной игре. Так что речь была именно об этом
Если это код на клиентской стороне -- то это некрасиво, пахнет, но неважно :)
... но мы уходим в холивар уровня "допустимо ли полагаться на UB если я проверил и оно работает".
Моё мнение -- можно, пока такой код покрыт юнит-тестом. В случае, обсуждаемом в топике, простой юнит-тест на декодер вскрыл бы проблему и нам было бы не о чем тут говорить...
Это стало результатом примерно 10 лет страданий и повторяющихся пересборок из-за бинарного поиска по коммитам, затрагивавшим AK.
Нехило так страдания в переводе умножились, с 10 часов до 10 лет :) Ну и некто Gunnar избежал в итоге жалоб в свой адрес, хотя казалось бы, их по логике должно было стать только больше… :)
Если баланс не сошелся - в нем есть ошибка.
Если баланс сошелся - ошибок две.
Мы чтобы такого не было, пытаемся итераторы в отладочной версии хештаблиц делать в обратном порядке, чтобы никто не зависел от них.
Я правда вообще не понял, зачем для массива пикселов нужны какие-то хэши и хаффманы. Видимо, я сильно отстал от программирования, в котором для print "hello world" теперь принято заводить всякие конструкторы-деструкторы.
Хаффманы вообще-то в стандарте JPEG присутствуют. Вот хеш-таблица тут - и правда вещь странная...
Я jpeg не ковырял, но вот это место в стандарте. В словарь засунули "Component specification parameters". Их формально может быть до 255 (хмм, мультиспектральный jpeg), поле "Ci" (8-битный id) решили сделать ключом.
Вот поэтому отладочные сборки хэш-таблиц от бигтеха и рандомизируют порядок элементов.
Просто структуру словаря надо делать упорядоченной по добавлению ключей. Как минимум иметь отдельную реализацию key-ordered контейнера. Столько проблем во многих случаях сразу уходит.
https://pypy.org/posts/2015/01/faster-more-memory-efficient-and-more-4096950404745375390.html
Как malloc сломала JPGLoader в Serenity, или Как выиграть в лотерее