🎄T
Вкратце, это для тебя прозвучит странно, но в такой парадигме имело бы смысл создать абстрактную базу данных
Size: a a a
2020 September 20
🎄T
Если не хочется портить структуризацию и поддерживаемость
🎄T
Базу данных по аналогии с хранилищем
🎄T
Потому что мы работаем с данными
🎄T
То есть у тебя будут списки отдельных компонентов и связаны они будут общим идентификатором
🎄T
И только эти отдельные списки компонентов в переборе будут намного более кэш-френдли
🎄T
И выиграют тебе достаточно много, в зависимости от объёма данных и прочего
🎄T
В любом случае это гарантированно будет быстрее, потому что это осознанный подход к программированию
🎄T
Вот пример короче
🎄T
В общем я наверное всю концепцию и высказал, а дальше уже преткновения будут
Y
Вот пример короче
И как это сделать в объектно-ориентированном язык?
🎄T
Так что вот, ничто не серебряная пуля, инструмент конечно нужно подбирать по задаче, но современное ооп ведёт немного не в ту сторону, особенно молодёжь, которая начинает с ооп языков, которые им в школе преподают И так далее (изначально тейк был про американские школы и ооп)
🎄T
И как это сделать в объектно-ориентированном язык?
Вполне просто, также как ты сейчас сделал
🎄T
Удалить хумана
🎄T
Создать функцию, которая будет паковать хумана по массивам
🎄T
Которая будет собирать хумана по массивам
🎄T
И итерацию уже делать по массивам данных например
🎄T
Для получения хумана можно два варианта рассмотреть
🎄T
Например первый - иметь список индексов, который определяет хумана по массивам его полей
🎄T
Второй - иметь в каждом массиве дополнительный айди, что лишит боли с индексами и параллелизмом, но добавит некоторое количество байтов (а зависимости от максимального размера) в перебор