Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: Ещё один редактор.  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 760
Тестовые данные кстати брал здесь. 20289767
И заметно, что потребление памяти растёт с ростом (строк / байт).
19 янв 18, 16:57    [21121100]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
Siemargl
Надо чтобы размер файла превышал размер оперативки, тогда не может. Проверь =)


Так чё проверять, это очевидно. Текстовый редактор должен разбить весь текстовый файл на строки, это можно сделать загрузив в память.
20 янв 18, 13:01    [21122407]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
mayton
Member

Откуда: loopback
Сообщений: 39209
Когда-то уже отвечал по треду. Добавлю.

Из best practices что мы используем на проекте.

По логам. Мы конфигурим appenders или logrotate таким образом чтобы логи были не больше 1Гб.
На проде и на дев-серверах и на QA. Логи имеют хронологию в виде суффикса который дописывается
в виде даты. Например.

catalina.out
catalina.2018-01-18.log
catalina.2018-01-19.log


Если возникает необходимость по быстрому посмотреть какой-то баг - то на сервере в консоли делаем
grep -r -F"OutOfMemory" $CAT_HOME/logs/
less -p "OutOfMemory" $CAT_HOME/logs/catalina.out

И прямо в less можно делать навигацию вверх-вниз по ключевым тегам.

Если все таки есть необходимость работать с клипбордом или с подсветкой синтаксиса (json, xml)
то мы качаем лог с сервера на свой десктоп и открываем в notepad++. Он довольно мощный
и не падает от толстых тестовых файлов. Ну по крайней мере я не встречал таких ситуаций.

Вообще в самой изначальной постановке - лог это не текстовый файл. Это sequence из независимых
строк (событий) где каждая имеет свой набор атрибутов типа метку времени, источник, ThreadID, и собственно месседж
и подходить к нему с позиции того что это некий неизменяемый замороженный снимок событий в прошлом.

Поэтому текстовый редактор для лога - это некая натяжка.

До кучи есть еще интересные программные продукты для анализа больших логов. Я к сожалению
не использовал ElasticSearch, но мы планируем внедрить в проект. Если у кого-то есть опыт - прошу
поделиться. Буду признателен.
20 янв 18, 13:20    [21122434]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
mayton
Если у кого-то есть опыт - прошу
поделиться. Буду признателен.


graylog2, работает на ElasticSearch, для логов просто незаменим. особенно удобен тем, что ведёт структурный лог, очень быстрый поиск с агрегацией, и на любую запись лога можно дать прямой линк, чтобы прикрепить к тикету. мастхев очень давно.

текстовые логи только для совершенно крайних и тяжёлых случаев, но они тоже должны быть.
20 янв 18, 13:35    [21122471]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
mayton,

ещё кроме логов, полезно вести также метрику. кто-то для этого использует тот же лог, мы метрику ведём в clickhouse.
20 янв 18, 13:35    [21122473]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
mayton
Поэтому текстовый редактор для лога - это некая натяжка.


натяжка здесь в слове «редактор», тот же FAR по F3 открывает файлы любого размера без давления на память.

только что открыл 15 гиговый файл фаром по F3, сделал поиск, нашёл в середине файла, фар при этом сожрал 12.5 мб оперативки.
20 янв 18, 13:38    [21122483]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
mayton
Member

Откуда: loopback
Сообщений: 39209
+1 я Far Ом пользуюсь уже более 15 лет. В нем ещё можно настроить цветовые схемы для подсветки синтаксиса.
20 янв 18, 15:17    [21122715]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6063
hVostt
Siemargl
Надо чтобы размер файла превышал размер оперативки, тогда не может. Проверь =)


Так чё проверять, это очевидно. Текстовый редактор должен разбить весь текстовый файл на строки, это можно сделать загрузив в память.
Ты ляпнул чушь, не подумав.

Довольно просто обойтись без полной загрузки.
20 янв 18, 19:55    [21123288]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
Siemargl
Ты ляпнул чушь, не подумав.

Довольно просто обойтись без полной загрузки.


какие интересные сказки ты нам рассказываешь
20 янв 18, 22:51    [21123629]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9023
hVostt
какие интересные сказки ты нам рассказываешь
Широко известный в узких кругах MultiEdit (DOS) редактировал файлы размером более доступных ему ~500Kb.
Подтормаживал на загрузке фрагментов, но работал.
20 янв 18, 23:03    [21123668]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
Basil A. Sidorov
hVostt
какие интересные сказки ты нам рассказываешь
Широко известный в узких кругах MultiEdit (DOS) редактировал файлы размером более доступных ему ~500Kb.
Подтормаживал на загрузке фрагментов, но работал.


лично мне известны проблемы при реализации текстовых редакторов, я этой задачей занимался в академических целях, изучал код других редакторов.

тот, кто говорит, что это «довольно просто», видимо считает, что разработка это какой-то вид магии, и надо просто скастовать парочку простых заклинаний.

ну и надо бы сходить к разработчикам ФАР-а и многих популярных редакторов и сказать, какие же они там тупицы, не смогли сделать то, что сделать «довольно просто».
20 янв 18, 23:56    [21123778]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9023
hVostt
тот, кто говорит, что это «довольно просто»
В моём сообщении слова "довольно" и "просто" не употребляются ни по отдельности, ни в словосочетаниях.
21 янв 18, 00:07    [21123788]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 760
mayton,

Есть ещё много других способов. Но удобнее всё-таки не перебирать 10 разных программ а взять один нормальный инструмент.
Разбивать логи по размеру не всегда удобно.
OutOfMemory это наивно просто. Обычно ищем сесию и смотрим что происходит паралельно в соседних. А если соседная заинтересовала, смотрим дальше на историю соседней. Тут нельзя включить grep. Но можно конечно метатся: less, блокнотик, grep, блокнотик, less ..., sed, sed, cat.
По крайней мере у меня такой опыт.
21 янв 18, 00:36    [21123839]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
mayton
Member

Откуда: loopback
Сообщений: 39209
Какая сессия? Вы о чем? Я tomcat привел в качестве примера просто. И аут-оф мемори придумал на ходу.
21 янв 18, 01:12    [21123887]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
DarkMaster
Member

Откуда: Donetsk,Ukraine
Сообщений: 6166
mayton
В нем ещё можно настроить цветовые схемы для подсветки синтаксиса.

Раскраска синтаксиса работает только в редакторе и при полной загрузке файла в память - синтаксис всегда надо раскрашивать с начала файла. Для больших файлов (от 1-2м) уже начинает заметно тормозить. Фаровский вьювер - тот да, влет. Но без синтаксиса.
21 янв 18, 15:00    [21124377]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
Basil A. Sidorov
hVostt
тот, кто говорит, что это «довольно просто»
В моём сообщении слова "довольно" и "просто" не употребляются ни по отдельности, ни в словосочетаниях.


а я и не говорил, что это невозможно. редактирование текстовых файлов без загрузки в память плохо дружит с рядовым функционалом: сохранение по требованию, undo, расчёт кол-ва строк, редактирование в середине, а не в начале или в конце, вставка/удаление строк, расставление переносов произвольным образом. и чтобы это быстро работало, и не портило файл.
21 янв 18, 22:18    [21124932]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9023
hVostt
редактирование текстовых файлов без загрузки в память плохо дружит с рядовым функционалом
Редактирование пары гигабайт "наивными алгоритмами" плохо дружит с чем угодно. Загрузка в память не особо меняет ситуацию.
Надеюсь, вы не станете возражать, что возможность грузить в память гигабайтные наборы данных - вполне рядовая вещь по сегодняшним временам.
22 янв 18, 06:04    [21125166]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
mayton
Member

Откуда: loopback
Сообщений: 39209
Автор в начале топика говорил про просмотр лога. Я думаю что тема топика - не редактор а viewer.
22 янв 18, 10:03    [21125493]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9023
mayton
Автор в начале топика говорил про просмотр лога.
седьмое сообщение топика.
22 янв 18, 10:12    [21125521]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
Basil A. Sidorov
Редактирование пары гигабайт "наивными алгоритмами" плохо дружит с чем угодно. Загрузка в память не особо меняет ситуацию.


меняет не просто "особо", а категорическим образом меняет всё.
22 янв 18, 10:16    [21125532]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3584
hVostt
Siemargl
Надо чтобы размер файла превышал размер оперативки, тогда не может. Проверь =)


Так чё проверять, это очевидно. Текстовый редактор должен разбить весь текстовый файл на строки, это можно сделать загрузив в память.

Не совсем так. Файл можно отобразить в память, затем пробежаться по нему и построить индексы по строкам.
27 янв 18, 23:00    [21144345]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
hVostt
Member

Откуда:
Сообщений: 15226
Arm79
Не совсем так. Файл можно отобразить в память, затем пробежаться по нему и построить индексы по строкам.


Всё верно, но:

1. для построения индекса, надо всё равно прочитать весь файл
2. если файл сильно большой, то сам индекс может оказаться огромным и не влезть в память
3. сохранение файла требует свободного места на диске, не меньше размера файла

но и реализация в разы усложняется, требуется очень много различных оптимизаций.
28 янв 18, 21:28    [21145661]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3584
hVostt
1. для построения индекса, надо всё равно прочитать весь файл

с отображением сильно быстрее

hVostt
если файл сильно большой, то сам индекс может оказаться огромным и не влезть в память

если хранить только позиции начала строк и их окончаний - индекс очень компактный :-)

hVostt
сохранение файла требует свободного места на диске, не меньше размера файла

Тут не поспоришь. Оперативно можно менять что-то в огромных файлах только тогда, когда новые данные по размеру как раз как старые. Или строки строго определенного формата и размера (типизированные). В общем, это не вариант.
28 янв 18, 21:44    [21145696]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9023
Arm79
если хранить только позиции начала строк и их окончаний - индекс очень компактный :-)
Самый компактный индекс хранит только смещения строк или только их длины.
Первый вариант предполагает четыре или восемь байт на строку, второй - два или четыре.
Для файлов, состоящих из коротких строк индекс займёт заметную долю от размера файла.
28 янв 18, 23:11    [21145821]     Ответить | Цитировать Сообщить модератору
 Re: Ещё один редактор.  [new]
mayton
Member

Откуда: loopback
Сообщений: 39209
1) Не обязательно хранить смещения всех строк. Можно индексировать страницы (грубо - 25 строк)
2) Смещения тоже можно складывать в двоичный файл. Над ним - сверху построить LRU-кеш.
3) Если отказаться от мгновенной фиксации вставок строк или удалений - то можно логгировать
изменения.

Понятное дело. Тема текстовых редакторов которые правят гига-байтные файлы не раскрыта.
Но и не секретна. Есть исходники notepad++. Пускай автор смотрит. Изучает. Я не думаю что
там сверх-умные алгоритмы. Тут самое сложное - даже не алгоритм а уяснение того
что должен делать редактор и как. Должен ли править шапку гигбайтныех файлов? Или нет?

Как говорили древние - LABOR ET PATIENTIA OMNIA VINCUNT.

А вот сорцы ноутпада https://github.com/notepad-plus-plus/notepad-plus-plus
29 янв 18, 00:12    [21145863]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Программирование Ответить