Bad allocation

[kompilainenn]

причем тут телепаты?

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

ну и на всякий случай еще:

ОО Calc 4.0.1 при работе с большими документами появляется ошибка "Bad allocation". При этом документ закрывается, не сохраняясь. 

попробуйте Либреофис 4.2 бета, просто ради интереса, если заработает, то значит проблема именно в ООо и именно версии 4.0.1

[souror]

попробуйте Либреофис 4.2 бета

попробую.
И еще один момент ошибка не всегда появляется.

[celler]

souror, только Вы не забудьте сделать копию файлов, а то версия 4.2 ещё очень сырая и ошибки там встречаются повсюду.
Что касается Bad allocation, то эта ошибка легко воспроизводится на любой версии LO и в Gnumeric - достаточно только увеличить количество ячеек с формулами. Отличие только в том, что этот предел у разных программ и версий разный. Интересно было бы узнать, происходит ли тоже самое в Линуксе. Если же предел не достигнут, то, по крайней мере LO, способен переварить очень сложные формулы в большом количестве. Причём это не зависит от размера памяти - раньше у меня было 2 гига, а сейчас 16 и ничего кардинально не изменилось. У меня бывало что он и по часу просчитывал все формулы. Единственный выход я пока вижу только в оптимизации таблиц, например использовании матричных формул вместо обычных.

[calc4fem]

64/32 bit может иметь значение в таких случаях.
Вообще конечно в таких случаях когда много формул - лучше использовать бейсик и формулы массива.

[celler]

В общем, провёл эксперимент,- поставил себе VirtualBox и в нём проинсталлировал Ubuntu 13.10 64-bit, выделив ей 4 Gb памяти. Там оказался LO 4.1.2.3, разумеется 64-битный. И в нём очень легко и быстро создал, сохранил и вновь открыл файл с более чем 4 миллионами формул. Файл получился размером 28 Mb формата .ods и в Виндовсе его смог открыть только Gnumeric.

[kompilainenn]

В общем, провёл эксперимент,- поставил себе VirtualBox и в нём проинсталлировал Ubuntu 13.10 64-bit, выделив ей 4 Gb памяти. Там оказался LO 4.1.2.3, разумеется 64-битный.

проведите все же эксперимент с ЛО 4.2 бета =)

[celler]

Про ЛО 4.2 бета я уже писал,- он в этом плане лучше, чем 4.1, но не намного. При попытке открыть в нём файл получаю bad allocation. Всё дело вероятно в том, что LO изначально предназначен для Линукса, а версия для Виндовса даже не 64-битная, что в данном случае важно. Файл прикладываю, можете сами попробовать.

[вложение удалено Администратором]

[ape]

Про ЛО 4.2 бета я уже писал,- он в этом плане лучше, чем 4.1, но не намного. При попытке открыть в нём файл получаю bad allocation. Всё дело вероятно в том, что LO изначально предназначен для Линукса, а версия для Виндовса даже не 64-битная, что в данном случае важно. Файл прикладываю, можете сами попробовать.

Дистрибутив для Майкрософт-ОС - х86, не win32 или i586, т.е. предназначен как для х64, так и х32. Не в битности системы дело. Ошибка присутствует в Windows_OS. А что в OS-X?

[DixiX57]

Файл прикладываю, можете сами попробовать.

Попробовал. Kubuntu 13.10 64b, Libreoffice 4.1.4.1. Открывается без проблем, сохраняется. НО! Процесс soffice.bin съедает 3.6 ГБ памяти (вся система при этом потребляет 4.5 ГБ). Проблема, на мой взгляд, именно в потреблении памяти (а значит и в механизме доступа, а значит и в "битности"). Хотя... мне не до сих пор не понятно, зачем нужен миллион строк. Для больших объёмов информации правильнее использовать базу данных. Всё равно, для обработки таких объёмов нужны функции агрегатирования.

[ape]

Проблема, на мой взгляд, именно в потреблении памяти (а значит и в механизме доступа, а значит и в "битности").

Нет, не в битности операционной системы:
- открыл файл за ~20 секунд на Ксеноне Е3 (Иви Бридж; RAM=16GB) под упралением Lubuntu-13.10_amd64 c помощью LibO-4.1.4.rc1 и LibO-4.2.0.beta2 (последняя - чуть быстрее);
- открыл файл за ~12 минут на Asus PC-1015n на Atom_N570 (RAM=2GB; SWAP=3GB на SDHC) под управлением Lubuntu-13.04_x86 с помощью LibO-4.1.2rc2.
Нетбук свопился, ПК - нет. Т.е. размер памяти и подкачка влияют только на время, необходимое для открывания файла.
Виновата только сборка, не учитывающая в чём-то специфику ОС Windows! А что в OS_X ??

[celler]

Offtop, но уже в который раз здесь спрашивают - зачем миллион формул? У меня вот Calc вместо швейцарского ножа - программа на все случаи - одна из самых часто используемых. Используется она как для более-менее серьёзных разработок, так и для некоторых разовых задач. В последнем случае не нужно ни какой оптимизации, а просто обычно необходимо быстро сделать какое-либо задание. Вот буквально последний пример такого задания. Есть 20000 строк текста и есть список из 50 слов. Необходимо найти все строки текста, в которых встречается хотя бы одно слово из списка. Здесь можно наверное придумать как наиболее оптимально решить такую задачу. А я поступил совсем просто. Транспонировал список из 50 слов на новом листе в одну строку. На основном листе в соседнем столбце с текстом записал формулу, которая ищет в ячейке А1 текста слово из ячейки А1 второго листа и в случае его присутствия, выдаёт 1. Растянул эту формулу на 50 ячеек вправо. Затем с помощью поиска и замены подкорректировал все формулы так, чтобы их можно было копировать вниз и скопировал их на все 20000 строк. Затем добавил столбец, который суммирует результат по всем 50 столбцам и получил в нём значения в тех строках, которые соответствуют первоначальному заданию. На всё про всё буквально несколько минут времени, но... при этом у меня получилось более миллиона формул.
Или вот в своё время использовал Calc как GIS. Как известно, карты разных масштабов имеют вполне определённую номенклатуру названий. Не очень сложно в Calc составить формулы, которые будут определять по любым реальным координатам название листа любого масштаба. Если в таблице сделать достаточно мелкую сетку ячеек, в качестве фона указать ссылку на реальную карту и в ячейки выводить информацию из базы данных населённых пунктов с их координатами, расположенную на другом листе, то, меняя лист карты, который отражается в виде фона и указывая в таблице его номенклатурное название, мы получим на фоне карты геопривязанные данные из нашей базы. И наоборот, можно сделать так, чтобы в ячейки, соответствующие положению на карте населённых пунктов можно было вносить их названия, а программа будет выдавать таблицу всех введённых названий и их географических координат. Так вот, поскольку разграфка требуется мелкая и ещё требуется масса вспомогательных ячеек, то общее количество формул получается достаточно большим.
Или вот прикладываю файл, показывающий карты-километровки, имеющиеся в свободном доступе в интернете. Такой же файл был и для 500-метровок, в котором ячеек соответственно в 4 раза больше. Эти файлы сделаны в ОО и всё там просчитано автоматически на основании данных из базы. Количество формул там очень большое.
А насчёт баз данных, во-первых, их нужно изучать и уметь ими пользоваться. Во-вторых, практически обязательно знание английского языка. Ну и не думаю, что ими так же удобно пользоваться как табличными процессорами. Я в своё время освоил Access и сделал в нём даже одну очень серьёзную программу, но уже много лет у меня нет потребности в использовании таких программ,- табличных процессоров достаточно.

[вложение удалено Администратором]

[celler]

Дистрибутив для Майкрософт-ОС - х86, не win32 или i586, т.е. предназначен как для х64, так и х32.

Про битность в LO нигде не написано, но тут в диспетчере задач в Windows 8.1 64 Bit случайно обнаружил - LibreOffice (32 Bit).

[kompilainenn]

диспетчере задач в Windows 8.1 64 Bit случайно обнаружил - LibreOffice (32 Bit).

а кстати правда, почему не собирают под винду ЛО 64-хбитный, а только 32-х?

[Hasim]

Какой есть компилятор у сборщика, на том и собирает.

[frob]

последнем случае не нужно ни какой оптимизации, а просто обычно необходимо быстро сделать какое-либо задание. Вот буквально последний пример такого задания. Есть 20000 строк текста и есть список из 50 слов. Необходимо найти все строки текста, в которых встречается хотя бы одно слово из списка.

grep -f wordslist text > result