<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
К сожалению без двойного прохода не получится. Опубликуйте<br>
List::Util::Internals и Scalar::Util::Internals вам будут благодарны<br>
программисты со сложными алгоритмами, где realloc становится<br>
проблемой.<br>
<div><div></div><br></div></blockquote></div><br>я собственно этот вопрос задавал на предмет может кто-то уже эту работу проделал.<br><br>тут переписали два модуля с Perl на XS. а поскольку алгоритмы не меняли, то вся разница в быстродействии (> 100 раз) упирается чисто в работу с памятью. вот собственно интересно стало, можно ли вернуться на perl пусть бы и с костылями.<br>
<br>PS: а кстати вот перловая инструкция вида <br><br>(%hash)[$index]<br><br>получается всегда полным перебором (от нуля до $index) выполняется? или я пропустил в документации какую-то функцию?<br><br>PS: писали сериализацию/десериализацию данных. обычную типа Data::Dumper, но с такой фичей: работа из event-машины. то есть и сериализация и десериализация идут ограниченными квантами. ну и event-машина при этом не блокируется.<br>
<br>в ближайшее время выльем на cpan<br><br>десериализация получилась быстрее eval, а сериализация медленнее Dumper раз в пять.<br><br>опять же вопрос - а не велосипед ли мы ваяли? может для event-машин кто-то делал что-то подобное? вот JSON::XS имеет инкрементальный парсинг, а в обратном направлении инкремента нет. хотя что самое интересное десериализацию можно сделать быстрее сериализации...<br>