Йоксель

Форум проекта

Йоксель » Главный форум

1. 

   Djelf
   Участник

   Спасибо за формулы, скорость всего в 2-3 раза ниже чем перебор по тз, даже на 100К строк работает приемлемо. Жду форматов, а то 1/3 выглядит грустно ;)
   А такое: sum(RC,RC) в формулах планируется? Частично то уже реализация есть...

   Отправлено 16 года(лет) назад #
2. 

   Oleg
   Администратор

   Спасибо за формулы, скорость всего в 2-3 раза ниже чем перебор по тз, даже на 100К строк работает приемлемо.

   А как тестировал? В частности, использовал атрибут Текст или Значение с типом "Число"?

   А такое: sum(RC,RC) в формулах планируется?

   Ну, надо бы конечно :)

   Отправлено 16 года(лет) назад #
3. 

   Oleg
   Администратор

   Дополнение. Про расчет формул я имею в виду операции над какими ячейками происходят? Над обычными ячейками документа, загруженного из Мокселя, или ячейки заполняются через атрибут "Значение" числовыми значениями? Потому что, если документ получен из Мокселя, то все ячейки текстовые и там еще преобразование из строки в число должно происходить. А это, скорее всего, не быстро (разбор строки, несколько операций умножения и т.д.)

   Отправлено 16 года(лет) назад #
4. 

   Oleg
   Администратор

   Кстати, на самом деле функция СУММ не нужна. Ибо заменяется существующими средствами. Например, суммирование чисел в 3-й колонке: R1C3+R2C3+R3C3+R4C3+...
   :DD

   Отправлено 16 года(лет) назад #
5. 

   Djelf
   Участник

   >А как тестировал?
   Таблицу заполнял напрямую, текст или значение - по скорости примерно одно и то же.

   Ну я и дерево ;( А смысл было замерять скорость расчета без вывода в таблицу? :D
   Выигрыш в расчете в тз = проигрыш в скорости вывода в тд. С учетом этого разницы уже практически нет, на 100К строк - доли секунды.

   З.Ы. В перегруженной из мокселя таблице скорость пересчета падает в 4 раза (по сравнению с созданной напрямую), при этом неважно были ли заполнены числа в мокселе или после перегрузки в йокселе.

   Отправлено 16 года(лет) назад #
6. 

   Djelf
   Участник

   Тест 5 вариантов заполнения

   Attachments

   1. СкоростьВычислений.zip (2.8 KB, 161 downloads) 16 года(лет) old

   Отправлено 16 года(лет) назад #
7. 

   Oleg
   Администратор

   В тесте 2 у тебя используется Область.Текст, а не Область.Значение. У меня это дает просадку при вычислении формул в 20%.

   В принципе, основная причина почему пересчет в ТЗ работает быстрее - это то, что память в ТЗ выделяется однократно под все значения, а в Йокселе под каждую вычисляемую формулу выделяется новая ячейка (отдельное выделение памяти). Сейчас у себя слегка подкрутил - при повторном вычислении стал проверять - есть ли уже ячейка - скорость уже становится близкой к ТЗ. ТЗ на 200 тыс. строк - 500мс, повторное вычисление формул: 650мс. Первое вычисление формул остается медленнее примерно раза в два. Можно еще кое-где подкрутить. Правда, ИМХО, сильно большого смысла в этом нет :)

   Отправлено 16 года(лет) назад #
8. 

   Oleg
   Администратор

   При сборе с аллокатором на dlmalloc первое вычисление формул происходит где-то за 750мс (раньше было 900-1000). Но dlmalloc, к сожалению, использовать наверное нежелательно.

   Отправлено 16 года(лет) назад #
9. 

   Oleg
   Администратор

   Правда, если использовать Значение вместо Текст, то заполнение документа становится медленнее :) Что впрочем логично - конвертация из одинэсного числа в йоксельное - вещь небесплатная.

   Отправлено 16 года(лет) назад #
10. 

    svoy
    Участник

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

    Отправлено 16 года(лет) назад #
11. 

    Oleg
    Администратор

    При переходе с P4 на C2 скорость загрузки mxl-файла на одном ядре выросла в шесть раз. Но это, думаю, связано с C2, а не компилятором :) Вообще, чтобы проявлялась польза компилятора Intel, программа должна создавать большую вычислительную нагрузку на процессор и работать с большими объемами данных.

    А в Йокселе все несколько по другому. Там объемы обрабатываемых данных довольно невелики и основную нагрузку составляют операции выделения/освобождения большого количества небольших блоков памяти. В таких случаях наибольшую роль играет скорость менеджера памяти, который от компилятора не зависит. В частности, в этой ветке: после замены менеджера памяти на более быстрый скорость работы подскочила на 25%. А это, например, сопоставимо с эффектом от перехода с компилятора VC6 на ICC (по отзывам - ускорение 30%).

    Многоядерность в Йокселе вообще не задействуется к сожалению. И пока не очень понятно, где бы ее можно было бы использовать.

    Так что, компилятор от Intel используется, в основном, чтобы была нормальная поддержка современного C++ и чтобы обеспечить максимальную совместимость с библиотеками 1С. Дополнительно тут еще есть дальний прицел - компилятор от Интел есть и для Linux. Соответственно, при создании линукс-версии Йокселя можно будет его задейстововать и избежать некоторого количества проблем.

    Отправлено 16 года(лет) назад #
12. 

    svoy
    Участник

    Многоядерность в Йокселе вообще не задействуется к сожалению. И пока не очень понятно, где бы ее можно было бы использовать.

    - перерисовка ячеек при скрытии/открытии строк/столбцов
    - пересчет формул
    - добавление строк
    - параллельная обработка при конвертации - там же ячейки независимо друг от друга можно обрабатывать
    - будущий построитель строк

    Отправлено 16 года(лет) назад #
13. 

    svoy
    Участник

    про менеджер памяти и маленькие куски данных - по идее им как раз может очень пригодится большой кеш современных corе2duo, хотя подозреваю что это делает сам процессор не спрашивая программу и компилятор

    Отправлено 16 года(лет) назад #
14. 

    Oleg
    Администратор

    Это как раз из тех задач, когда либо ускорение вообще не нужно, либо когда гипотетические потоки будут иметь большое количество общих данных и постоянно тупить на блокировках. Соответственно, при попытке реализовать многопоточность можно наоборот получить замедление относительно однопоточного варианта.

    Отправлено 16 года(лет) назад #
15. 

    Gavrish
    Участник

    Можно ли формулы установленные в ТабличномДокументе вывалить в Excel?

    Отправлено 16 года(лет) назад #
16. 

    Oleg
    Администратор

    Достаточно документ сохранить в формате Excel. А разве что-то не сохраняется?

    Отправлено 16 года(лет) назад #
17. 

    Gavrish
    Участник

    Сори, все получилось, спасибо огромное!

    Отправлено 16 года(лет) назад #
18. 

    Pavel
    Участник

    >Кстати, на самом деле функция СУММ не нужна. Ибо заменяется существующими средствами. Например, суммирование чисел в 3-й колонке: R1C3+R2C3+R3C3+R4C3+...

    Прекрасно работает в йокселе, но при сохранении в эксель при слишком длинной формуле переносится некорректно. Очень жду хотфкс с поддержкой этой функции

    Отправлено 16 года(лет) назад #
19. 

    Pavel
    Участник

    После определённой длины формулы в эксель сохраняется просто число со значением, формулы в ячейке нет

    Отправлено 16 года(лет) назад #
20. 

    Oleg
    Администратор

    >Кстати, на самом деле функция СУММ не нужна. Ибо заменяется существующими средствами. Например, суммирование чисел в 3-й колонке: R1C3+R2C3+R3C3+R4C3+...

    Прекрасно работает в йокселе, но при сохранении в эксель при слишком длинной формуле переносится некорректно. Очень жду хотфкс с поддержкой этой функции

    Вообще-то, это была шутка :)

    После определённой длины формулы в эксель сохраняется просто число со значением, формулы в ячейке нет

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

    Отправлено 16 года(лет) назад #
21. 

    Pavel
    Участник

    >Вообще-то, это была шутка :)
    Как бы то ни было - работает! :-)

    > Я вычислил предельное количество элементов в формуле и при сохранении формул, которые не укладываются в предел, они тупо заменяются обычным значением.
    Я так и думал

    Предложение: добавить свойство области "ФормулаExcel", в которой можно задать произвольную формулу. В йокселе такая формула не вычислялась бы, а срабатывала при открытии файла в экселе. Возможно?

    Отправлено 16 года(лет) назад #
22. 

    Oleg
    Администратор

    Нет. Формулы в Excel хранятся не в виде строк, а в виде распарсенных (двоичных) элементов. Поэтому нужен парсер формул и конвертер в формат Excel. А это уже, по сути, поддержка этой формулы в Йокселе.

    Отправлено 16 года(лет) назад #
23. 

    Pavel
    Участник

    Эх, а как бы красиво получилось :)
    PS Так что, ожидать поддержку SUMM?

    Отправлено 16 года(лет) назад #
24. 

    Oleg
    Администратор

    Думаю, можно ожидать появления СУММ через определенное время.

    Отправлено 16 года(лет) назад #
25. 

    kir
    Участник

    Ура , появилось Sum()

    вопрос, а как работает со скрытыми ячейками ??
    можно ли реализовать поведение аналогично
    РассчитатьСумму() ?

    Отправлено 16 года(лет) назад #
26. 

    Oleg
    Администратор

    Скрытые ячейки будут учитываться. Метод "РассчитатьСумму" имеет два режима: с учетом скрытых ячеек и без. Поэтому SUM и так имеет поведение как в "РассчитатьСумму" :). ИМХО, делать зависимость формул от видимости ячеек не совсем логично. Вот и в Excel скрытые ячейки учитываются. Так что, если мы сделаем такой ТОЛЬКОВИДНОСУММ(), то у нас будет большой гемор с конвертацией этого добра в Excel.

    Отправлено 16 года(лет) назад #
27. 

    kir
    Участник

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

    Отправлено 16 года(лет) назад #
28. 

    Сергей
    Участник

    ДА! Вопрос по скрытым ячейкам... сталкивался кучу раз, когда "ненужную" инфу не удаляли, а просто "не показывали" - в итоге вроде 30 строк, а грузишь - е! 4000 строк.
    .
    поэтому вопрос:
    - есть ли возможность при чтении экселя в ТЗ или в табличный документ доп.параметром (последним!) указывать "не читать скрытые", при неуказании этого параметра - читается все.. - тогда весь написанный код не прдется менять...
    .
    Ваше мнение, мастер?

    Отправлено 16 года(лет) назад #
29. 

    Oleg
    Администратор

    Мне кажется, основная проблема это то, что при загрузке скрытые строки загружаются как видимые. Поэтому достаточно будет только добавить поддержку видимости строк для конвертера. Ну и, возможно, какую-то настройку для загрузчика в ТЗ - чтобы не учитывал скрытые строки.

    PS. И "мастером" не обзывайся :)

    Отправлено 16 года(лет) назад #

RSS экспорт этой темы

Отправить сообщение

Вы должны войти в систему, чтобы оставлять сообщения.