Slow konqe on a PXA250

[Simon Hausmann]

On Wed, Nov 20, 2002 at 09:24:14PM +0530, Mayuresh Kathe wrote:
> 
> 
> On Wed, 20 Nov 2002, Simon Hausmann wrote:
> 
> > On Wed, Nov 20, 2002 at 11:28:18AM +0100, Daniel Stenberg wrote:
> > > Hm, does Konq/e create new threads often? I found a post over at the
> > > armlinux-kernel list that identified a problem in the Linux process creation
> > > code for the PXA...
> >
> > konq/e does not make use of threads (clone(2) and friends) , it
> > still creates child processes for network IO though. I'd be
> > surprised though if the creation of the processes is what gives the
> > bad performance you experience. (I mean... you'd notice that in the
> > whole system I guess)
> 
> Hey, Simon, wouldn't it more efficient to have threads instead of separate
> processes? (Qt/e threads)

I doubt it'd make a noticable difference (performance and memory
wise) . Under Linux 2.4 usually threads are regular processes, so
the creation time is about the same. In terms of memory usage: At
startup konq/e fires off a separate process, which then is used for
the creation of the io job processes. At this point there is few
memory allocated, so the copy-on-write shouldn't hurt (at all) and
the io should have almost no unnecessarily unshared memory. Whether
shared memory (as for threads) would really give much performance
compared to the pipes would need detailed profiling tests, but I
think the main cpu hog remains the actual renderer (as it's supposed
to be) .


> > I'm clueless about the PXA cpus. Are they particularly bad or good
> > at integer or fpu arithmetic? Do they lack an fpu at all like the
> > arm modules?
> 
> PXA are an extended version of StrongARM, I guess with added support for
> USB and a couple of other things within the chip (which was outside
> earlier)

Ohh, that sounds cool. Hm, I guess they lack an fpu then. konq/e
performs some floating point operations. But I haven't found them to
be a problem on arm based devices, yet. Sure, the are emulated, but
it's not that konq/e is as slow as Daniel described, so I guess it
must be something else then :-(


Simon