Ghost2004
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Так, в версии 19 июня, с одной стороны, одной проблемой стало меньше - rep:1400mb+rep:1400mb+lzma:216mb распаковывается без тормозов в виде лишних tempfile'ов по умолчанию, т.е. не меняя настройки ld. А вот с другой - теперь распаковать rep:1700mb+lzma:216mb просто так не выходит, так как макс. свободный блок <1800mb, посему вылетает ошибка can't allocate memory . Приходится добавлять -ld1800mb - там таки создаётся tempfile - как в версии от 18 июня по умолчанию. Знаю, настройки для win32 больно экстремальные, но в принципе оно трудно добавить в -ld по умолчанию ограничение в размер максимально доступного целого блока? Потому как лучше этого в смысле использования 2 gb+ памяти тут может быть лишь выделение её сразу для всей цепочки алгоритмов (т.е. выделяется сначала 1700 mb для rep, а потом 216 для lzma - тогда в том примере без проблем можно обойтись даже без tempfile при распаковке), или хотя бы автоматическое добавление tempfile каждый раз при обнаружении нехватки памяти для последующего алгоритма (т.е. как только lzma:216mb распаковала первый блок, а для последующего rep:1700mb виртуальной памяти не хватает, автоматически вставлять между ними tempfile и писать в него результат распаковки). Это наверное сложнее?
З.Ы. Так, с версией от 23 июня ситуация получается хуже - даже в случае rep:1400mb+rep:1400mb+lzma:216mb вылетает can't allocate - хотя версия от 19 июня всё распаковывает обходясь одним tempfile без настройки вроде -ld1800mb (впрочем, для версии от 23 числа и она не помогает, всё равно вылетает can't allocate, вообще настройки ld не помогают - даже с tempfile после распаковки lzma про любому вылезает can't allocate). Тот архив был получен версией 18 июня. |
