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
