Bulat_Ziganshin
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата: 1)я переписываю все основные операции на асме (+ на паскале для проверки) с оптимизациями, что увеличивает скорость распаковки (теперь с уменьшением количества обращений срепа к вводу/выводу думаю это даст нормальный плюс) | именно так дилетанты подходят к оптимизации: давай чё-нибуть ускорим! правильная оптимизация начинается с анализа времени, затрачиваемого на каждую операцию, и выявления узких мест. в srep сама распаковка идёт практически мгновенно - на уровне скорости memcpy, вычисление md5 - и то порядка 300мб/с на моей тачке. т.е. явно куда быстрее, чем может прокачать диск если же srep пойдёт в конвейере с lzma, то всё будет определяться скоростью. распаковки lzma (40-50 мб/с). лучшее что здесь можно сделать - обеспечить параллельную работу lzma и srep на разных ядрах процессора. а теперь скажи мне как этого добиться? Цитата: 2)размер srep.dll, в которой только функция распаковки, откомпилированная на интеловском компиляторе, составляет примерно 90кб. Размер,получаемый на асме внутри моей длл - несколько килобайт. | ну так отрежь от неё весь лишний код и откомпили чем-нибудь другим. имхо, для неё вполне подойдёт .obj сгенерённый bcc, чтобы включить его в delphi dll простой линковкой учти, что нынешний код распаковки в несколько раз сложнее. старый-то переписать было делом 5 минут Цитата: Все основные процессы распаковки в данном случае будут идти через твою unarc.dll (как будет возможность потестю выложенную тобой новую дллку со срепом). Например цепочка упаковки precomp->srep->lzma все равно будет распаковываться в 2 этапа - сначала lzma+srep через unarc.dll | мы говорим о разных вещах. ты - об srep внутри .arc через arc.ini, это понятно и так работать будет я говорю о том, что является коньком твоей библиотеки - распаковка цепочек типа tar+srep+lzma. это можно делать целиком в памяти, вопрос в поддержке этого в isdone Цитата: (и "con" вместо имен файлов не помогает) | con - это консоль Цитата: Я конечно могу внедрить в чужой процесс нужный мне код, дабы прекомп хавал подсовываемые данные от других модулей (и то нужен контроль над входными и выходными данными в той же unarc.dll), но тогда антивири и файрволы ругаться будут. | а ты не можешь перманентно модифицировать precomp.exe/dll? Цитата: да уж были подобные просьбы от иноязычных | понимаешь, английский - это языке международного обмена. если ты сделал что-то оригинальное, то надо описать это на английском, чтобы хакер из какого-нибудь китая не мучался, изобретая велосипед собственно, как я понимаю, там есть chm (у него какие-то исходники? дай их мне), скрипт и ещё немного строк в dll, которые надо проверить на корректность перевода? у меня есть знакомый техн. переводчик, я ему отдам. собственно правильный подход к переводу - писать по-русски и отдавать профессионалам |