примерно полторы минуты (97 секунд если быть точным). Начал копать - проблема детектится сразу - зависание на чтении отладочной. Проект большой, отладочной много. Ок, начинаю смотреть своим ридером - с ним проблем нет, он читает в районе двух секунд всю отладочную. Вот этим https://github.com/AlexanderBagel/ProcessMemoryMap/blob/master/RawScanner/RawScanner.CoffDwarf.pas
Ок, проверяю а почему у них так? Выясняется, я читаю как, читаю запись, потом сопостовляю её через case по типу с нужным полем. У них же - берется поле - ИЩЕТСЯ!!! где лежит нужная запись причем поиск идет по тупому от нуля до каунта!!! Пииисец. Экспоненциальная зависимость. Странно что не 200 секунд читает
а я тебе говорил не ходить тудой
Ну...есть мнение, что так сделано потому что отладочная может и отдельно лежать. С другой стороны, может быть прост как осилили
Стикер
Это которые в lnfodwrf.pas ?
Это пофиг где отладочная сидит - тут сам алгоритм не верный
А я это именно щас и собираюсь делать, тут без вариантов
Ты напиши им, что они тебе бабок должны )
нет, там ваще тихий ужас, я про "\lazarus\components\fpdebug\fpdbgdwarfdataclasses.pas"
Там вообще много где линейные поиски
Это нормально, я когда прототип клепаю, то не заморачиваюсь преждевременной оптимизацией. Могу и поиск в цикле делать, и копировать значения лишний раз, если это упрощает код. И вроде как на малых данных все быстро и удобно. А потом приходит образец данных на сотню гигов, и там уже нужно хоть немного, но оптимизировать
Тут нужно не оптимизировать - тут нужно всё переписывать
Щас только вопрос, как это исправить малой кровью? Моя читалка пока что не заточена на лазарь, хотя самое оптимальное именно её испоьзовать ибо там все весьма оптимизировано
Да, так тоже бывает. Можно еще попытаться "переходник" сообразить, чтобы в чужой монастырь со своим самоваром не лезть. Но это удручает.
Ну щас все обложу профилировщиком и буду искать узкое место, начну хотябы с этого
Сначала обложил всякими хловами...
Тем чем я это обложил когда нашел - сюда постить нельзя :)
Я так и начал писать, но это же основа...
А где там ужас? Выглядит старомодно, классически, но вроде не похоже на говнокод.
ничо что там кэша нет и при чтении дварфа производится миллионы операций чтения с харда по одному два четыре байта? Я уж не говорю что там сам дварф на миниальном уровне ваще читается (это я про lnfodwrf.pp если чо)
Щас тебе лазаруслфилы напихают про то, что так и должно быть и испокон веков наши деды так делали и если не нравится, напиши как тебе надо
оно и в винде так-же читает :) А тебе задайся вопросом, почему моя это парсит за 2 секунды, а их только на чтение тратит по полминуты? :)
Это достаточно TDbgFileLoader поправить
Чтобы мне что-то напихать нужно обладать как минимум моей квалификацией. Я сам кому хочешь написаю полную кукушку :)))
на всякую мутоту внутри RTL, но не "с харда" я в свое время тупо заменяя "школьный" Read на крупноблочное чтение из TStream и занудный ручной парсинг - тоже поднимал скорость ого-го. Но это чисто RTL, винда с железом делали что могли в обоих случаях
там много чего придутся переделывать. Ладно это оффтоп, не отвлекайте - профайлер надо пилить нормальный сначала
В TDbgFileLoader.OpenStream заменить TFileStream на TMemoryStream + LodaFromFile займет совсем мало времени =)
А почему нет кэша? 😱
не я автор
А, ты про fpdebug - ну да, есесно, я думал ты про lnfodwrf
А, это да, говнокод. Но там в TEReader вроде есть буфер. Маленький совсем, но есть.
Хм, странно, у меня 7500 уникальных адресов преобразуются в строку "файл,номер линии, функция" за меньше чем секунду отладочная ~ 300Мб а, не, обманул, дольше - 5,7 сек
а у меня все адреса (более миллиона ста тысяч) за 2 секунды :)))
Одно дело в отладчике читать, другое в вылетевшей программе. В отладчике конечно все надо кэшировать оптимизировать. В программе при развороте стека можно и подождать, но не усугубить поломку дальше
Разные механизмы используются, у них там ваще толи три толи четыре реализации читалок дварфа
Обсуждают сегодня