AkelPad Forum Index AkelPad
Support forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Проблема при работе с большими файлами (~ 5 Гб)
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    AkelPad Forum Index -> Discussion (Russian)
View previous topic :: View next topic  
Author Message
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Thu Dec 09, 2010 1:39 pm    Post subject: Reply with quote

FeyFre wrote:
Goodvin
Я вижу два выхода:
1. Либо учим Акел(а заодно и плагины) работать со свопингом, что совсем не просто и займет уйму(уймище) времени.
2. Либо делаем Акел 64-битным(и перекладываем всю ответственность на кол-во памяти у пользователя), что немного быстрее, но я не уверен что мы имеем достаточно опыта миграции на 64, и выловим все подводные камни(что опять таки выльется в доп. время), да плагин тоже перевести нужно будет.

На мой скромный взгляд - алгоритм работы с гигантскими файлами немного в стороне от этого.
Например, связан с индексированием файла и работой по индексу.
Возможно, есть смысл посмотреть как работает с гигантскими файлами пресловутый вышеупомянутый EmEditor. Что делает со свопом, какие временныые файлы создает и т.п.

FeyFre wrote:

3. А разделить файлы на куски поменьше не пробовали? Я так понимаю качество обработки от этого не пострадает.
Увы, разделять не выйдет. Весь 5-гиговый файл - это цельный структурированный XML. Если разбить его на куски, то невозможно будет отследить по смыслу XML-объекты внутри него. Файл потеряет человекочитабельность.
Back to top
View user's profile Send private message
Fr0sT



Joined: 24 Jul 2007
Posts: 876

PostPosted: Thu Dec 09, 2010 3:57 pm    Post subject: Reply with quote

Goodvin
Quote:
Эти 5 гигов - это XML-дамп большой базы данных.
Как раз в plain-тексте дампа поправить несколько строчек, а потом загрузить исправленное снова в БД значительно проще и нагляднее.

Хм, я сам ненавижу, когда на вопрос начинают вместо ответа предлагать варианты, как это сделать окольнейшими путями, но всё-таки, не легче ли это реализовать SQL командой или хранимой процедурой?
Что касается EmEditor, то я поражён его талантами в области огромных файлов. И еще при этом сохраняют возможность редактирования! Боюсь, если добиться тех же умений от Акеля, он будет стоить столько же, сколько Em Smile
Back to top
View user's profile Send private message
FeyFre



Joined: 07 Aug 2007
Posts: 2054
Location: Vinnitsa, Ukraine

PostPosted: Thu Dec 09, 2010 4:13 pm    Post subject: Reply with quote

Quote:
Увы, разделять не выйдет. Весь 5-гиговый файл - это цельный структурированный XML. Если разбить его на куски, то невозможно будет отследить по смыслу XML-объекты внутри него. Файл потеряет человекочитабельность.
Выше сказано что это дамп БД. Я так догадываюсь что это дамп релятивной БД. А раз так, и в БД оно лежит уже разбито по самостоятельным подобъектам: строчки, поля в строчках. А раз так, то разбить и обработать не проблема. Да, нужно будет сделать несколько итераций по всем файлас, с сохранением промежуточных данных. Но это пока единственный фаш выход.
И да, Fr0sT прав: на какой делать таким обходом? SQL-лями можно сделать почти всё(остальное делаем клиентом который SQL пускает). Другие варианты смахивают на велосипедостроение.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Thu Dec 09, 2010 7:10 pm    Post subject: Reply with quote

Fr0sT wrote:
Goodvin
Quote:
Эти 5 гигов - это XML-дамп большой базы данных.
Как раз в plain-тексте дампа поправить несколько строчек, а потом загрузить исправленное снова в БД значительно проще и нагляднее.

Хм, я сам ненавижу, когда на вопрос начинают вместо ответа предлагать варианты, как это сделать окольнейшими путями, но всё-таки, не легче ли это реализовать SQL командой или хранимой процедурой?
если бы такое было применимо, вопрос бы вообще не стоял.
А редактировать дамп нужно как раз тогда, когда с БД работать нет возможности, в основном это случаи всякого ремонта, отката, восстановления целостности (надо загружать разные периоды в БД) и т.п.
При интенсивной работе возникают периодически.
и когда времени мало - редактировать простой xml в текстовом редакторе значительно эффективнее, чем поднимать второй сервер БД, которого может и не быть в пределах доступности.


Fr0sT wrote:

Что касается EmEditor, то я поражён его талантами в области огромных файлов. И еще при этом сохраняют возможность редактирования! Боюсь, если добиться тех же умений от Акеля, он будет стоить столько же, сколько Em Smile

Вот потому меня и волнует вопрос - нужно ли кому-то в принципе этим заниматься, есть ли к этому интерес?
Если есть, то я бы пытался всячески помогать и т.д.
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен. И указать предельный размер файла было бы неплохо.


Last edited by Goodvin on Thu Dec 09, 2010 7:23 pm; edited 1 time in total
Back to top
View user's profile Send private message
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Thu Dec 09, 2010 7:20 pm    Post subject: Reply with quote

FeyFre wrote:
Quote:
Увы, разделять не выйдет. Весь 5-гиговый файл - это цельный структурированный XML. Если разбить его на куски, то невозможно будет отследить по смыслу XML-объекты внутри него. Файл потеряет человекочитабельность.
Выше сказано что это дамп БД. Я так догадываюсь что это дамп релятивной БД. А раз так, и в БД оно лежит уже разбито по самостоятельным подобъектам: строчки, поля в строчках. А раз так, то разбить и обработать не проблема. Да, нужно будет сделать несколько итераций по всем файлас, с сохранением промежуточных данных. Но это пока единственный фаш выход.
И да, Fr0sT прав: на какой делать таким обходом? SQL-лями можно сделать почти всё(остальное делаем клиентом который SQL пускает). Другие варианты смахивают на велосипедостроение.

Вы всё верно говорите, друзья, но !
Почему-то всё время в общении смещается вектор с решения конкретной задачи на критику условий этой самой задачи.
Я ж не дурак, и прежде, чем приходить сюда с вопросом, тщательно всё обдумывал, искал варианты, много всего пробовал.
И уж если пишу, что вот есть такая задача "визуально читать и редактировать большой файл порядка 5 гигабайт", то задача у меня именно такая.
И именно такая возможность задекларирована у программы AkelPad.
Но, как выяснилось, функция не работает.
Притом, если другие программы, не сумев открыть такой большой файл, честно об этом сообщают различными способами, AkelPad просто молча показывает не весь файл.
И мой приход сюда был в надежде на то, что обнаруженная мной неработоспособность заявленной функции будет кому-то интересна и мой опыт поможет сделать AkelPad лучше, и я готов в этом улучшении участвовать в меру сил.

А мне раз за разом рассказывают, что я хочу не того, чего надо, и делать мне надо что-то другое.
[пожимает плечами с недоумением]
Back to top
View user's profile Send private message
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5423

PostPosted: Fri Dec 10, 2010 5:35 am    Post subject: Reply with quote

Goodvin
Quote:
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Та фраза благополучно перекочевала из AkelPad 2.x.x. На практике мной проверялись файлы от силы пару сотен мегабайт.
Back to top
View user's profile Send private message Send e-mail
DV



Joined: 16 Nov 2006
Posts: 852
Location: Kyiv, Ukraine

PostPosted: Fri Dec 10, 2010 8:18 am    Post subject: Reply with quote

Instructor wrote:
Та фраза благополучно перекочевала из AkelPad 2.x.x. На практике мной проверялись файлы от силы пару сотен мегабайт.

Стало быть, реально должны поддерживаться файлы где-то до 2 ГБ (что, по идее, ограничивается адресацией с помощью 32-битных указателей). А для не-Юникодных файлов - где-то до 1 ГБ, потому что для них требуется дополнительная память для преобразования в Юникод.
Back to top
View user's profile Send private message
Fr0sT



Joined: 24 Jul 2007
Posts: 876

PostPosted: Fri Dec 10, 2010 8:23 am    Post subject: Reply with quote

Goodvin
Quote:
Почему-то всё время в общении смещается вектор с решения конкретной задачи на критику условий этой самой задачи.

А так всегда, если задача не особенно коррелируется с понятиями других (ака весьма экзотична) Smile
В принципе, я был бы очень рад, если бы Акель стал пошустрее обрабатывать хотя бы 50-меговые файлы, не говоря уже о бОльших, но 5 гигов - это уж совсем экстремально. Скажи, а этот Em умеет работать с разными кодировками? То есть если файл, например, в KOI8 - он преобразует его правильно? У Акеля-то основная загвоздка в том, что после прочтения файла он перегоняется в utf16.
Back to top
View user's profile Send private message
FeyFre



Joined: 07 Aug 2007
Posts: 2054
Location: Vinnitsa, Ukraine

PostPosted: Fri Dec 10, 2010 8:24 am    Post subject: Reply with quote

(Писал я вчера такую тераду, да забыл запостить)
Если кратко:
Моя позиции(и наверное ещё кого-то здесь):
Акел не потянет Ваш 5Гб файл в виду 32 битного ограничения по памяти(минимум). Это не баг, это врожденное. И потому мы пытаемся подсказать как решить Вашу задачу без АкелПада. Это не агрессия.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
VladSh



Joined: 29 Nov 2006
Posts: 2615
Location: Киев, Русь

PostPosted: Fri Dec 10, 2010 9:00 am    Post subject: Reply with quote

Goodvin
Instructor, если он против, то обычно сразу говорит об этом.
Т.е. 2 варианта: либо уберут упоминание об этом, либо есть надежда, что реализуют (или во всяком случае попробуют).
Я не редактирую такие большие файлы, но, с моей точки зрения, было бы лучше, чтобы AkelPad обладал такими возможностями, это было бы его реальное преимущество перед другими, в отличие от подсветок и т.п., которые есть почти везде.

Касательно x32.
Компа на x32 уже не купишь. Глянуть на любые сайты-сборники прог, так уже около 50% есть версии под x64, и их количество продолжает расти. А там где есть версии под x64, x32-верии в плане каких-то серьёзных изменений уже никто не будет допиливать, т.к. это зря потраченные время и ресурсы. Ясно одно, x32 - это вчерашний день.
Back to top
View user's profile Send private message Visit poster's website
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5423

PostPosted: Fri Dec 10, 2010 12:34 pm    Post subject: Reply with quote

Goodvin
Quote:
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Убрал. Проверил на Windows x64 с 4Gb ОЗУ - при достижении порога в 2Gb начинают выдаваться сообщения о нехватке памяти, затем программа с загруженным куском файла работает очень нестабильно.
Back to top
View user's profile Send private message Send e-mail
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Fri Dec 10, 2010 1:26 pm    Post subject: Reply with quote

Instructor wrote:
Goodvin
Quote:
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Та фраза благополучно перекочевала из AkelPad 2.x.x. На практике мной проверялись файлы от силы пару сотен мегабайт.
Понятно.
Back to top
View user's profile Send private message
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Fri Dec 10, 2010 1:28 pm    Post subject: Reply with quote

Fr0sT wrote:
Goodvin
Quote:
Почему-то всё время в общении смещается вектор с решения конкретной задачи на критику условий этой самой задачи.

А так всегда, если задача не особенно коррелируется с понятиями других (ака весьма экзотична) Smile
В принципе, я был бы очень рад, если бы Акель стал пошустрее обрабатывать хотя бы 50-меговые файлы, не говоря уже о бОльших, но 5 гигов - это уж совсем экстремально. Скажи, а этот Em умеет работать с разными кодировками? То есть если файл, например, в KOI8 - он преобразует его правильно?
Проблем ни разу не встречал.
Насколько я понимаю - работает правильно.
Back to top
View user's profile Send private message
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Fri Dec 10, 2010 1:30 pm    Post subject: Reply with quote

FeyFre wrote:
(Писал я вчера такую тераду, да забыл запостить)
Если кратко:
Моя позиции(и наверное ещё кого-то здесь):
Акел не потянет Ваш 5Гб файл в виду 32 битного ограничения по памяти(минимум). Это не баг, это врожденное. И потому мы пытаемся подсказать как решить Вашу задачу без АкелПада. Это не агрессия.

Это понятно.
Но багом точно является тот факт, что АкелПад, не сумев открыть большой файл, ничем мне как пользователю не сообщил. И ладно бы, если бы не сумел открыть - не показал вообще ничего, но он показывает только часть файла и молчит, словно всё в порядке.
Такое поведение программы я считаю неправильным.
Это и есть баг.
Надеюсь, это будет исправлено авторами.
Back to top
View user's profile Send private message
Goodvin



Joined: 08 Dec 2010
Posts: 15

PostPosted: Fri Dec 10, 2010 1:32 pm    Post subject: Reply with quote

Instructor wrote:
Goodvin
Quote:
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Убрал. Проверил на Windows x64 с 4Gb ОЗУ - при достижении порога в 2Gb начинают выдаваться сообщения о нехватке памяти, затем программа с загруженным куском файла работает очень нестабильно.

Понятно.
Спасибо за внимание к моей проблеме.
А чем может быть объяснено поведение программы, когда она показывает мне лишь часть файла и ничего не сообщает - ни ошибок, ни варнингов?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    AkelPad Forum Index -> Discussion (Russian) All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


SourceForge.net Logo Powered by phpBB © 2001, 2005 phpBB Group