Да! Было-бы намного круче, если бы сеть в первых циклах обучения пыталась различными способами взаимодействовать с объектами, и на основе этого уже выделяла их в разные группы враг/предмет/и т.п.
Что с «противоречивыми» оценками? Например — взрывать бочку впритык к себе — плохо, а взрывать бочку которая впритык к противнику — хорошо? Это закладывалось в изначальные знания сети, или она этому училась сама? И училась ли?
P.S. Судя по видео, переключение «боевой» и «исследовательской» сети происходит топорно — бот не умеет стрелять во врага и «стрейфится» по направлению к аптечке/патронам. Да и просто в «боевой» бот обычно либо стоит либо бежит только вперёд.
В таком случае можно было бы зафиксировать дату последней смены пароля у пользователя (проставить дефолтный epoh), если она меньше чем дата релиза «X» то производить проверку без учёта регистра и выводить предупреждение, если после — проверять регистрозависимо.
Да, тут уже дальше оптимизировать проблематично:
1. Bitmap Heap Scan — постгресу пришлось перепроверять версионность строк, это нормально для таблиц в которых часто происходят update/delete — если же таблица не из таких, то надо проверить когда был последний vacuum/analyze таблицы.
2. Sort — совсем грошёвые cost'ы, максимум что можно сделать — проверить сортировки в индексах, в том ли порядке они, как в запросе.
P.S. Можно попробовать избавиться от Bitmap Index Scan — разбив на несколько CTE, что бы получить Index Only Scan'ы.
WITH temp_rows AS (
SELECT n
FROM medley
ORDER BY n OFFSET 500000
LIMIT 30
)
SELECT * FROM medley WHERE medley.n = ANY(ARRAY(SELECT n FROM temp_rows)::uuid[])
Спасибо за ответ. А если не секрет, можете рассказать как происходит мониторинг чтения памяти? Слабо разбираюсь в этой теме. Suspend процесса товарищам не поможет?
Почему выбран путь распознавания по скриншоту? И почему собираетесь эмулировать нажатия клавиш/кликов?
Гораздо производительней и проще было бы оперировать/отслеживать внутренние события самой игры.
Тем более раз разработчики такие общительные, может подскажут некий внутренний api.
P.S. Планетарки… Сколько нервов было на них потрачено.
Очень рад за Ваш прогресс в разработке Vivaldi. Уже сейчас мне бы хотелось перейти на него — но меня останавливает отсутствие заявленного "Vivaldi Sync". Не подскажете когда он появится?
Да! Было-бы намного круче, если бы сеть в первых циклах обучения пыталась различными способами взаимодействовать с объектами, и на основе этого уже выделяла их в разные группы враг/предмет/и т.п.
P.S. Судя по видео, переключение «боевой» и «исследовательской» сети происходит топорно — бот не умеет стрелять во врага и «стрейфится» по направлению к аптечке/патронам. Да и просто в «боевой» бот обычно либо стоит либо бежит только вперёд.
Как исправить эту ошибку?
1. Bitmap Heap Scan — постгресу пришлось перепроверять версионность строк, это нормально для таблиц в которых часто происходят update/delete — если же таблица не из таких, то надо проверить когда был последний vacuum/analyze таблицы.
2. Sort — совсем грошёвые cost'ы, максимум что можно сделать — проверить сортировки в индексах, в том ли порядке они, как в запросе.
P.S. Можно попробовать избавиться от Bitmap Index Scan — разбив на несколько CTE, что бы получить Index Only Scan'ы.
Вот результат для моей таблицы, с ~500к записей.
EXPLAIN ANALYZE
SELECT *
FROM product
ORDER BY guid
OFFSET 200000
LIMIT 10
"Limit (cost=53081.04..53083.70 rows=10 width=427) (actual time=5338.193..5338.218 rows=10 loops=1)"
" -> Index Scan using "pk-product" on product (cost=0.42..107495.58 rows=405026 width=427) (actual time=0.026..5201.130 rows=200010 loops=1)"
"Planning time: 0.679 ms"
"Execution time: 5338.266 ms"
EXPLAIN ANALYZE
SELECT *
FROM product as a
JOIN (SELECT guid FROM product ORDER BY guid OFFSET 200000 LIMIT 30) as b ON b.guid = a.guid;
"Hash Join (cost=6114.90..35463.31 rows=30 width=443) (actual time=246.895..6361.194 rows=30 loops=1)"
" Hash Cond: (a.guid = product.guid)"
" -> Seq Scan on product a (cost=0.00..27829.26 rows=405026 width=427) (actual time=0.004..5820.195 rows=405026 loops=1)"
" -> Hash (cost=6114.53..6114.53 rows=30 width=16) (actual time=243.653..243.653 rows=30 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 2kB"
" -> Limit (cost=6113.31..6114.23 rows=30 width=16) (actual time=243.567..243.618 rows=30 loops=1)"
" -> Index Only Scan using "pk-product" on product (cost=0.42..12379.81 rows=405026 width=16) (actual time=0.011..129.707 rows=200030 loops=1)"
" Heap Fetches: 0"
"Planning time: 0.181 ms"
"Execution time: 6361.272 ms"
EXPLAIN ANALYZE
WITH temp_rows AS (
SELECT guid
FROM product
ORDER BY guid OFFSET 200000
LIMIT 30
)
SELECT * FROM product WHERE guid = ANY(ARRAY(SELECT guid FROM temp_rows)::uuid[])
"Index Scan using "pk-product" on product (cost=6115.26..6199.24 rows=10 width=427) (actual time=243.227..243.329 rows=30 loops=1)"
" Index Cond: (guid = ANY ($1))"
" CTE temp_rows"
" -> Limit (cost=6113.31..6114.23 rows=30 width=16) (actual time=243.037..243.089 rows=30 loops=1)"
" -> Index Only Scan using "pk-product" on product product_1 (cost=0.42..12379.81 rows=405026 width=16) (actual time=0.015..130.086 rows=200030 loops=1)"
" Heap Fetches: 0"
" InitPlan 2 (returns $1)"
" -> CTE Scan on temp_rows (cost=0.00..0.60 rows=30 width=16) (actual time=243.041..243.133 rows=30 loops=1)"
"Planning time: 0.154 ms"
"Execution time: 243.386 ms"
Гораздо производительней и проще было бы оперировать/отслеживать внутренние события самой игры.
Тем более раз разработчики такие общительные, может подскажут некий внутренний api.
P.S. Планетарки… Сколько нервов было на них потрачено.