UVviewsoft forums

оказывается Сублиме имеет лексер для todo.txt format.
https://github.com/dertuxmalwieder/SublimeTodoTxt
создайте запрос на лексер на нашем github. посмотрю.

Вы его сделали:

CudaText-lexers/Todo.txt at master · Alexey-T/CudaText-lexers
https://github.com/Alexey-T/CudaText-le ... r/Todo.txt
4 days ago

Многое, что вам нужно, УЖЕ реализовано в CudaText!
Пример - https://synwrite.sourceforge.net/forums ... 474#p18474

Всех и автора с праздниками!

Радуют и в то же время удивляют упорство и настойчивость автора в преодолении багов.
Вроде выходит новая версия, багов должно быть меньше, но появляются.
И в добавлении новых функций по запросу!
И автор быстро откликается и исправляет, и добавляет, без страха и упрека!

UPD:
и отвечает на вопросы, и пишет и выпускает обновления.
А CT гораздо лучше ST!

Где автор?
Куда дели Алексея?!

С наступающим мужским днем и всего самого наилучшего!

Здравствуйте!


cudatext.github.io/history.txt https://cudatext.github.io/history.txt :

1.211.0 (2024/03)

+ add: text search without RegEx has big speedup on huge lines; e.g. for line len=400K, with 25K matches, 'Count all'/'Select all'/'Mark all' are improved from ~30 sec to ~0.5 sec
+ add: text replacement (with and without RegEx) has big speedup on huge lines; e.g. for line len=400K, with 25K matches, 'Replace all' is improved from ~110 sec to ~0.5 sec

Огромное восхищеие и вопрос - за счет чего достигнут такой прогресс?

Еще раз огромное спасибо за CudaText!

поясню.
про первый пункт.

код работал так - в цикле мы вызываем ф-цию "ищи в строке с таким-то номером".
это работало так - для строки длиной 400к, мы вызывали ф-цию поиска и она 25К раз (т к в цикле) вызывала чтение строки длиной 400к. а чтение строки длиной 400к из хранилища это медленно. а оно еще и 25к раз выполнялось в цикле.

сделал оптимизацию - "передадим саму строку в ф-цию поиска".
тогда строка длинной 400к читается _только один раз_.

про второй пункт.
mass replace делался так - мы 1- читали строку из хранилища, 2- меняли в ней подстроку, 3- писали строку в хранилище.
так делалось 25к раз.

после оптимизации стало так - 1- читаем строку из хранилища и помним ее в строке-буфере, 2- прочие 25к замен делаем в _этой строке-буфере_, 3- пишем строку-буфер в хранилище

Спасибо за разъяснения и за такую сильную оптимизацию!

пожалуйста...

Неделю назад тестировал китайскую флешку 2 ТБ (примерно за 600 рублей купил на Алиэкспресс) создавая на ней огромные файлы командой Один файл примено 275 ГБ, другой 485 ГБ.
Скорость записи 5 МБ/с, отмонтирование идет 15 минут, светодиода нет. Ну да, а что хотеть за 600 рублей и 2 ТБ?!
Так как есть мнение, что там контроллер пишет фейковые файлы по кругу, то
открыл с CudaText файл 485 ГБ в шестнадцатеричном режиме.
Пролистал, вроде файл консистентый (правильный термин?), без разрывов.
По смещению последней строки пересчитал в калькуляторе - объем файла соответствует 485 ГБ!


А открыл CudaText файл 485 ГБ в шестнадцатеричном режиме всего за несколько секунд!
(Да, стоит учесть, что это не с SSD, а с довольно медленной флешки).

Огромное восхищение и вопрос - за счет чего достигнут такой прогресс?