Нестандартная ширина отчёта - критичное падение производительности
Нестандартная ширина отчёта - критичное падение производительности
Добрый вечер, уважаемые!
Столкнулся с такой проблемой. При создании отчёта, который имеет формат листа A4, но ширину большую, в прилагаемом примере 56 см., отчёт формируется дико медленно. Вместе с select'ом из базы и прорисовкой в MDI форме занимает 10-12 сек. при том, что FastReport.Net (Имхо, говно полное, просто предыдущий проект был на нём в Дельфе, поэтому сейчас всё переводим под Stimul и на Шарп) рисует его примерно также, иногда на несколько секунд быстрее (примерно 7-8). Но всё это ерунда, самое важное, это если сравнить производительность на слабых компах, а именно на Celeron 2.4 Гц и 512 Мб RAM (ещё есть Celeron'ы 3.0 Гц и 1 Гб RAM, на них проверить пока не успел, это уже на след. неделе). Так вот отчёт на стимуле (кот. во вложении) на этом селероне формируется чуть больше 2 минут, в то время, как на фастрепорте он формируется приблизительно 40-45 сек.
А всё дело в том, что у нас таких селеронов довольно много и время прорисовки для нашей компании очень критично, т.к. выводить будут большие отчёты и по 500 страниц и по 1000, и сколько будет выполняться отчёт очень важно.
При этом на Core2Duo этот же отчёт выполняется не более 10-11 секунд, это общее время, а рисуется примерно 7-8 секунд. Но результат на лицо - на старых машинах прорисовка страдает очень сильно.
В приложении полностью рабочий проект. На форме две кнопки, - одна запускает Stimul, другая FastReport, до этого подгружая xml'ный файл с данными. После формирования отчёта можно посмотреть на форму, там будет указано время - общее и прорисовки (это самое главное), общее не берём, т.к. из xml'я, понятно инфа грузится долго, а в реале она тянется с Oracl'иного сервера.
Соответственно вопрос: можно ли как-то улучшить движок или ещё что-либо сделать, чтобы поднять производительность именно прорисовки отчёта. Да, не вопрос, мы юзаем уже годовалую версию, возможно Вы уже что-то изменили с тех пор, если это так и производительность поднимется до FastReport'а или близко, то купим новую версию, это не проблема, главное скорость.
P.S. Понятно, что можно upgrad'ить компы, что мы и делаем постепенно, но их очень много, десятки, а суммарно таких компов у нас в компании где-то 70-80, поэтому вопрос очень актуальный, учитывая, что таких отчётов будет порядка 20, и формировать их люди будут каждый день, а ждать 5 минут или 10 - разница есть.
[url= http://www.rapidshare.ru/1417567]
Столкнулся с такой проблемой. При создании отчёта, который имеет формат листа A4, но ширину большую, в прилагаемом примере 56 см., отчёт формируется дико медленно. Вместе с select'ом из базы и прорисовкой в MDI форме занимает 10-12 сек. при том, что FastReport.Net (Имхо, говно полное, просто предыдущий проект был на нём в Дельфе, поэтому сейчас всё переводим под Stimul и на Шарп) рисует его примерно также, иногда на несколько секунд быстрее (примерно 7-8). Но всё это ерунда, самое важное, это если сравнить производительность на слабых компах, а именно на Celeron 2.4 Гц и 512 Мб RAM (ещё есть Celeron'ы 3.0 Гц и 1 Гб RAM, на них проверить пока не успел, это уже на след. неделе). Так вот отчёт на стимуле (кот. во вложении) на этом селероне формируется чуть больше 2 минут, в то время, как на фастрепорте он формируется приблизительно 40-45 сек.
А всё дело в том, что у нас таких селеронов довольно много и время прорисовки для нашей компании очень критично, т.к. выводить будут большие отчёты и по 500 страниц и по 1000, и сколько будет выполняться отчёт очень важно.
При этом на Core2Duo этот же отчёт выполняется не более 10-11 секунд, это общее время, а рисуется примерно 7-8 секунд. Но результат на лицо - на старых машинах прорисовка страдает очень сильно.
В приложении полностью рабочий проект. На форме две кнопки, - одна запускает Stimul, другая FastReport, до этого подгружая xml'ный файл с данными. После формирования отчёта можно посмотреть на форму, там будет указано время - общее и прорисовки (это самое главное), общее не берём, т.к. из xml'я, понятно инфа грузится долго, а в реале она тянется с Oracl'иного сервера.
Соответственно вопрос: можно ли как-то улучшить движок или ещё что-либо сделать, чтобы поднять производительность именно прорисовки отчёта. Да, не вопрос, мы юзаем уже годовалую версию, возможно Вы уже что-то изменили с тех пор, если это так и производительность поднимется до FastReport'а или близко, то купим новую версию, это не проблема, главное скорость.
P.S. Понятно, что можно upgrad'ить компы, что мы и делаем постепенно, но их очень много, десятки, а суммарно таких компов у нас в компании где-то 70-80, поэтому вопрос очень актуальный, учитывая, что таких отчётов будет порядка 20, и формировать их люди будут каждый день, а ждать 5 минут или 10 - разница есть.
[url= http://www.rapidshare.ru/1417567]
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте,
Разберемся. Сообщим о результатах здесь.
Спасибо.
Разберемся. Сообщим о результатах здесь.
Спасибо.
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте,
Пришлите пожалуйста архив на support@stimulsoft.com. С рапиды не распаковывается к сожалению.
Спасибо.
Пришлите пожалуйста архив на support@stimulsoft.com. С рапиды не распаковывается к сожалению.
Спасибо.
Нестандартная ширина отчёта - критичное падение производительности
Переслал архив на почту.
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте,
Архив получен. Спасибо. Проанализируем на что уходит время.
Спасибо.
Архив получен. Спасибо. Проанализируем на что уходит время.
Спасибо.
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте,
У нас есть версия, которая работает на 30% быстрее.
Пожалуйста, проверьте свой почтовый ящик.
Спасибо.
У нас есть версия, которая работает на 30% быстрее.
Пожалуйста, проверьте свой почтовый ящик.
Спасибо.
Нестандартная ширина отчёта - критичное падение производительности
День добрый, уважаемые!
Мне на почту так ничего и не пришло.
Вышлите пожалуйста повторно, то, что Вы выслали на ...
--
С уважением,
Леонид
Мне на почту так ничего и не пришло.
Вышлите пожалуйста повторно, то, что Вы выслали на ...
--
С уважением,
Леонид
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте Леонид,
Письмо ушло.
Спасибо.
Письмо ушло.
Спасибо.
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте Леонид,
Проверьте пожалуйста почту.
Спасибо.
Проверьте пожалуйста почту.
Спасибо.
Нестандартная ширина отчёта - критичное падение производительности
Здравствуйте,
Похоже до Вас не доходят наши письма.
Сообщите нам альтернативный почтовый ящик для отправки сообщений.
Спасибо.
Похоже до Вас не доходят наши письма.
Сообщите нам альтернативный почтовый ящик для отправки сообщений.
Спасибо.