[Scribus] Is scribus slow?

[PLinnell]

On Thu, 2004-06-24 at 18:49, Timo Springmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> hi list!
> 
> I'm new to this list (and to scribus). I'm an experienced Linux user since 7
> or 8 years and since a few years interested in graphics and design. Since two
> years I work at a small (Linux-) Company in germany and in this work position
> I have to do more and more dtp.
> 
> Since a few days I mostly took OpenOffice.org Draw for this job but two days
> ago I was really frustrated with Draw and I looked for some alternatives. I
> knew since a few month that scribus exists and I thought this is the right
> time to give it a look.
> 
> After playing with scribus for a few hours, I have two big impressions:
> powerful (I really like the pdf functions) and slow.
> 
> I tested scribus on different machines (slowest is athlon xp1600+ with at 512
> MB ram) and it's really slow with larger textframes (i.e. 100x150mm) or
> bigger pictures. I tried different versions of scribus (1.1.7, different cvs
> debian packages and even self compiled versions). Moving these frames is
> really slow, editing text is no fun and when I switch to a different virtual
> screen and then back scribus needs a seconds until the page is drawn
> completly. This is happening in a document (size: DIN-A4) with only one page.
> I think this is getting worse when I have to do larger documents, isn't it?
> Now my question: is this only me (my version of scribus, my favour of linux,
> my machine, my life) or is this a known 'problem'?
> 
> I really would like to make scribus my favorite dtp application, but I think
> this slowness drives me crazy after working with it for a few hours in real
> world documents.
> 
> Besides this little backdraw, Scribus is really great and powerfull
> application. It can do almost all the things I need.
> 
> Timo
> 
> - --
> Gravity is a myth, the Earth just sucks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 

Hi,

Performance is somewhat subjective, but that said compared to the other
professional DTP apps I work with Scribus is faster in some areas
(loading, some exports) and slower in others, but not horrendously
slower. This comes from someone who used Pagemangler 1.5 on a 286 with a
runtime version of Windows 2.1 and still has Quark 3.32 kicking around
somewhere.

FYI, I run and have run Scribus since 0.37 on a PII 450 with 768 Mb of
ram and an ATA-100 disk quite comfortably. This includes long documents
and highly graphical layouts. Last week I opened an 80 page year book
and it was usable, as well as exporting a 242 Mb PDF :)

Today I ran it on a dual Xeon with 1 GB of ram and it was certainly
fast. I opened a test file of 90 pages and switching between them was
instantaneous - even first to last page.

The most recent 1.1.x versions are certainly faster than the 0.x and
1.0.1 versions.

I think one thing might be at play is the way you are editing text.
Scribus is *not* a word processor and defining styles in advance and
using the story editor is recommended. PageMaker works the same way and
text is often written in another app of choice then imported into
frames. Then styles are applied.

A DTP app is far more precise about text handling and this does slow
down text re draws, but for example, Scribus is not worse than Pagemaker
in my experience. 

Things I would note for optimization:

IME libart_lgpl should be recompiled with full on optimization for your
arch: e.g i386 is not good. I always rebuild the source RPMS with
-march=i686 or better depending on the machine. The littlecms libraries
are the same. adding march=i686 or better makes a 30-50% difference in
measured tests in applying conversions. Although libart itself is
written in C, it's full of floating point math which is handled better
when SSE or MMX extensions are enabled. 

*Always* compile with your specific arch - example:

export CXXFLAGS="-march=pentium3" then run ./configure

All x86 systems are somewhat register starved compared to other
processors like Alphas. So adding -fomit-frame-pointer can help, but you
lose all debugging info at least until we see GCC 3.5

I have a Fedora-1 system and use the GCC 3.4 compiler exclusively for
compiling Scribus. It is probably worth 10% all by itself in its ability
to generate faster c++ code. GCC 3.4 is much stricter about c++ code and
happily even with -Wall, Scribus compiles without complaint. If your
distro has add on GCC 3.4 packages that work, I would use them for all
c++ apps ( as long as they compile).

Hope that helps,
Peter