[Scribus] No Speeding Zone

[PLinnell]

On Thursday 31 March 2005 18:52, wayne wrote:
> On Thursday 31 March 2005 06:09 am, Chris Turchin wrote:
> > i posted a similar malaise a while back. its apparently a known
> > issue with large text frames. my experience however, was only
> > that text entry in the frame was dreadful, not the whole app. the
> > workaround for me was to use the storyboard editor rather than
> > editing text directly in the frame.
> >
> > HTH.
> >
> > --chris
>
> I would do that except that just opening the storyboard editor
> takes a long time, up to 30 seconds. Then, maneuvering within the
> editor is just as slow.
>
> Here's another interesting thing that I've since discovered. The
> slowdown occurs mostly on page 1 of this 2 page document. Whenever
> I move to page 2 (with the page selector scroll box on the bottom
> of the page), everything speeds up. I found that I can edit page 1
> paragraph styles from page 2 (linked files) easily. But some things
> like positioning, I have to do on page 1:(
>
> Wayne
> _______________________________________________


Hi,

Reports about performance need to have some data and hardware specs to 
be helpful. Test cases with sample files are also really helpful.

Processor:?
Distro:?
Source or package?
what does top say about memory usage or other running processes ?
Memory / Swap Size ?
Disk Size/Speed/IDE or SCSI ?
Build date.?
-march and CXXFLAGS
gcc -v output

In my experience supporting DTP apps, hardware needs for optimal 
performance are somewhat different from games and more common office 
applications. 3D performance is meaningless. Fast disk access is 
sometimes more important than processing speed.  The way DTP apps 
work is sometimes slightly different than other apps. Example, both 
Scribus and other DTP apps scan for fonts more intensively than a 
common text editor. DTP apps commonly work on single large files 
which do not have indexes like a DB would. 

I have written more extensive comments about DTP and hardware in essay  
about supporting Pagemaker here : 
http://atlantictechsolutions.com/pmfaq1.html

That said, until very recently, I have tested every version of Scribus 
since 0.3.7 on a PII 450 with 768 Mb of RAM and an ATA-100 7200 rpm 
disc. 

With that kind of hardware, I was able to test very large files and 
never was unable to load even large or long documents. I even re-ran 
some of the import stress tests for the Open Office importer. (~600 
pages imported in one go.)

Enabling pre-linking reduced startup time to about the same as a 2.6 
Ghz Xeon without pre-linking. (~4-5 seconds with similar numbers of 
fonts installed.)

While longer to load with the new functionality, both 1.2.2cvs and 
1.3.0cvs are over all the best performing in my experience.

There are some thingswhere 1.3.0 is faster, some things in 1.2.2 are 
faster. 1.2.2cvs loads files faster, but 1.3.0 is faster to render 
and switch between pages for example.

If a report said : 1.2 did this in x.xx seconds and 1.3.0cvs did the 
same task in y.yy seconds - that - gives us something meaningful to 
look for.

1.3.0cvs is not a baby-eating monster, but there is a lot of major 
code refactoring going on underneath, hence those warning signs when 
opening/saving files.

We do take performance issues seriously. I know Craig Bradney stepped 
through 20-30 recompiles to chase down weird crashes and performance 
issues. Chasing them down can involve many many variables. Giving us 
meaningful info makes our job a lot easier.

Cheers,
Peter