Редактировалось 1 раз(а), последний 2017-03-04 23:46:38

Владд,
во-первых, вот это

единственное, что можно сделать это убрать начальную загрузку строки в StrList, и сразу производить замену.

[size=-2]------ Добавлено в 13:59

не надо. Обработать нужно изначально Unix строки и поэтому замена стоит верная.

Если так, то да. Но так как в схеме -- нет. StrList добавляет #10#13, а к ним затем еще #13 добавляется.

Редактировалось 1 раз(а), последний 2017-03-04 23:46:38

Для строк в 3мб не удивительно. Быстрее замену сделать не получится. В данном случае по хорошему было бы заменить символ
на и выдавать в поток после каждой замены указатель на строку, идущую до этого . К сожалению в данном пакете такое не возможно без использования InlineCode и знания Delphi

Редактировалось 1 раз(а), последний 2017-03-04 23:46:38

Владд, нельзя ли всетаки код вставлять в соответствующие теги?


такая схема пригодна только для небольших строк. Но даже в ней делается слишком много копирований, на которое уходит процессорное время.

Чушь какая-то. У меня таблица в 3 mb грузится за 18 сек (в самом худшем варианте за 30). А таблица парисруется по столбцам и по содержимому гораздо сложнее, чем просто убирание символа #13.

Редактировалось 1 раз(а), последний 2017-03-04 23:46:38

nesco, а есть уверенность в наличие полного представления о происходящем в приденном примере, чтобы так лихо сравнивать производительность с чем-то

Stream в руки - и с пестней

Вообще-то большой уверенности нет, но и окультно заявлять о том, что виноват именно StrList, тоже чести не делает. Если убрать именно StrList'ы и проверить быстродействие, то насколько оно прибавится? Вот что по этому поводу пишет Кладов

[size=-2]------ Добавлено в 15:55

Вот похоже, это и тормозит -- именно компонент Replace. И без разницы для этого компонента, убрать или заменить.

Кладов не делает замен. Он нулики лепит в исходный текст и накапливает PChar-ы в List-е
Берешь, смотришь - и никаких фантазий.

А я чего против, что ли. Я совсем про другое. Вот про это