Быстрая работа со строками
Тк мой редактор работает с документами word, в нем очень много строковых переменных. Сейчас он делает свое дело примерно за 5 минут, что никуда не годится. 3 секунды - норм. Подозреваю, что самое быстрое - оперировать со строками в бинарном виде. Есть какие-то приемы для повышения быстродействия?
|
Ответ: Быстрая работа со строками
Ничего не понятно. Что за редактор? Где ты это делаешь и что пытаешься получить?
"Обычные" способы работы со строками какие, если не "бинарные"? |
Ответ: Быстрая работа со строками
В блице, допустим есть много-много операций типа Left, Right, Mid, Instr. Они все тяжелые. Если например строки преобразовать в банки и Left, Right и тд выделять как диапазон значений в банках, проводить там нужные операции, а в конце опять преобразовывать в строки. Это будет быстрее? Или есть какие-то другие способы быстро проделать нужные операции над строками.
|
Ответ: Быстрая работа со строками
Общо сказать сложно. Конкретную задачу, как правило, можно оптимизировать сведя работу к двиганию указателей, игре с chr(0), и многократному использованию памяти. Но это требует определённой сноровки и может сделать код менее гибким для последующих изменений (преждевременная оптимизация).
|
Ответ: Быстрая работа со строками
|
Ответ: Быстрая работа со строками
Ссылку сейчас смотреть некогда, просто уточню: у нас речь сейчас об алгоритмической (аналитической) или вычислительной (практической) оптимизации? Понятия связанные, но всё же.
|
Ответ: Быстрая работа со строками
И то и другое. Главное, чтоб работало быстрее. Нужна быстрая альтернатива функциям Left, Right, Instr.
Вот алгоритм Бойера-Мура на практике, де-факто самый быстрый алгоритм поиска подстроки в строке (Реализация на FreeBasic с вставкой Asm): Быстрее в 10 раз обычного Instr. Код:
#INCLUDE "crt.bi" |
Ответ: Быстрая работа со строками
Ну дак блин ты сразу пиши что тебя надо то. Если бы ты сразу написал что тебе нужен быстрый поиск подстроки тебе бы сразу дали направление. Быстрого Left, right которые учитывают культуру не существует. Быстрый left, right без учета культуры это memcpy на строках где символ в памяти имеет фиксированную длину. + во многих случаях можно со строкой работать без её копирования (это дает прирост скорости).
|
Ответ: Быстрая работа со строками
Тут вот какая вещь по поводу Left, Right. В некоторых языках (в том числе в блице) скорость их выполнения мало зависит от длины строки, а в некоторых ЯП на коротких строках Left, Right работают быстрее, а на длинных медленнее.
Значит всё-таки можно короткие строки ускорить в десятки раз. |
Ответ: Быстрая работа со строками
От длины строки и не должна зависеть. Зависит от длины подстроки образуемой.
Если ты в Си и исходная строка тебе более не нужна, то: left - просто ставишь терминирующий байт после последнего в подстроке; right - ставишь указатель на начало подстроки. (ну и про очистку памяти потом не забыть надо) |
Ответ: Быстрая работа со строками
Значит в PureBasic 5.5 какая-то функция Left интересная.
В общем, примерно вот такой код: Код:
For i = 0 to 30000 FreeBasic: 28 мс (Строки Си) PureBasic: 3840 мс Но если уменьшаем количество итераций в обоих циклах допустим до 300 (точно не помню до скольки), то результаты будут такие: Blitz3D: 12 мс FreeBasic: 9 мс PureBasic: 2 мс Может, конечно, ошибка какая-то, хз. Может в PB что-то заглючило от слишком длинной строки. InStr тоже бывает двух типов: - Зависит от длины строк (выигрывает на коротких строках) - Алгоритм Кнута — Морриса — Пратта - Не зависит от длины - Алгоритм Ахо — Корасик Может с Left такая же история? |
Ответ: Быстрая работа со строками
Эксперимент поставлен некорректно.
С таким же успехом можно сделать вывод, что в PB работает сборщик мусора, включившийся после того, как ты понавыделял память - непонятно: на провис повлияло копирование длинных строк или общее количество копирований? Ну и ещё по мелочи ("прогрев", адекватность синонимов, статистическая устойчивость по моменту вызова и количеству вызовов, условия по загрузке цп, памяти) :mad: Если ты исследуешь зависимость от одного параметра - так и варьируй его сперва в одном приложении и в широком диапазоне. А потом уже проделывай аналогичное в других языках. |
Ответ: Быстрая работа со строками
В общем, всё сложно... Ладно, всё-равно я в принципе уверен, что FB быстрее работает(через библиотеку Си), по крайней мере во всех других тестах (вычисления, перевод чисел в строку) он работал процентов на 20 в среднем быстрее, его и буду юзать. Хотя вот FindString в PB работает даже быстрее раза в 1.5, чем InStr в FB.
Я просто не знал, что от длины строк не зависит, хотел с большой длиной потестить. В итоге по сравнению с блицем прирост производительности со строками максимум в 1.5 - 2 раза, не такой уж он и медленный. Остается делать ставки на многопоточность, ну и сам код упрощать. Я то думал, что блиц тормоз, о чем тут на форуме твердят постоянно. Думал щас как возьму крутой транслятор бейсика в Си с последующей компиляцией на GCC и скорость в 100 раз быстрее будет. Хрен там! :-D |
Ответ: Быстрая работа со строками
Щозанах :4to: Сегодня запускаю похожий код, результаты совсем другие:
Blitz3D - 1 мс FreeBasic - 2140 мс PureBasic - 19 мс Импер, объясни поподробнее, как правильно писать код то? Или где об этом почитать? 3000 символов - не такая же большая строка, 1-2 страницы А4. Код: UPD: Перезагрузил комп, FB - 0,8 мс. |
Ответ: Быстрая работа со строками
Поставь задержку на секунду к примеру перед подсчетом для "прогрева".
|
Часовой пояс GMT +4, время: 15:09. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot