the tool to understand where the slowishness comes from
seems to be  valgrind

i used it once and found out the culprit was scPainter::endLayer method,
costly and called too many times.
it'd be interesting to test and see if its the same in your situation.

JLuc

Le 13/06/2015 01:34, William Bader a ?crit :
>
>
>> Date: Fri, 12 Jun 2015 08:22:15 -0400
>> From: John at wexfordpress.com
>> To: scribus at lists.scribus.net
>> Subject: [scribus] Scribus and long documents.
>>
>> Scribus has a serious flaw, one that
>> limits its practical utility to short documents.
>> This is not a flaw susceptible of a quick fix, or
>> even a slow fix.
>>
>> A book length  document of 100 pages or more
>> slows the program down to a point that is not
>> tolerable. If one breaks down the document into
>> ten page segments then problems occur in page
>> numbering, the TOC, indexing and so on.
>
> Could you post a sample document?
> It might be possible to build a version of Scribus with gcc -pg profiling to 
> have an idea of what is happening.
> If you double the number of pages, is the slowness predictable? Does it get 
> twice as slow or four times as slow?
> Are the 100 pages all linked text frames so that any change to the first page 
> requires recalculating everything through to the last page?
> Is the book divisible into short chapters so that the text frame on the last 
> page of one chapter does not have to be linked to the text frame on the first 
> page of the next chapter?
> I'm not a Scribus developer, but the solution might be changing the display 
> to recalculate only currently visible pages.  Many laptops and PCs now come 
> with 16GB of RAM, so memory should not be a problem.  It might be possible to 
> store the starting layout state of each page as the page is processed, and 
> then when you modify a page, the recalculation could run from the page that 
> you changed forward to the last visible page on the screen and mark the 
> remaining pages as currently uncalculated (or queue them for recalculation on 
> a low priority thread).
> Regards,William
>
>                                       
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.scribus.net/pipermail/scribus/attachments/20150612/884bc4a7/attachment.html>
> ___
> Scribus Mailing List: scribus at lists.scribus.net
> Edit your options or unsubscribe:
> http://lists.scribus.net/mailman/listinfo/scribus
> See also:
> http://wiki.scribus.net
> http://forums.scribus.net
>



Reply via email to