On Wed, Dec 18, 2002 at 04:50:23PM +0100, Lubos Lunak wrote: > > Hello, > > I hope this is the right place for this. Please review, comment and possibly >apply the attached patches. With XFree4.2.x, XIM initialization takes about >66% of QApplication object initialization. This is mainly because of awful >pthread mutexes performance (to express it decently), and repeated processing >of the same data. The patches are done against XFree-4.2.x sources, but the >affected files don't show any big changes in webcvs. All patches are for >xc/lib/X11/ . > > The easy ones first: > > imLcPrs.patch > - this one replaces getc() with getc_unlocked() - with LinuxThreads linked >in (all KDE apps) getting rid of some locking always makes a noticeable >difference :-/ . I don't think libX11 needs anywhere locked access to files, >but this one is opened in a single thread in _XimCreateDefaultTree() anyway. >Manpage says getc_unlocked() is POSIX.1, so I hope there's no problem with >this one.
It might be safest to make sure that the _unlocked version is only referenced on platforms where thread support is enabled. Maybe '#ifdef XTHREADS' is sufficient for that. > lcFile.c.patch2 > - the same, but this time it's gets() with gets_unlocked() - the manpages >says that glibc includes it, but it's not standardized. Would it be possible >to include this one together with some configure check (probably something >like #ifdef __GLIBC__ )? I think LinuxThreads comes usually only with glibc. Assuming all glibc 2.x versions have it, then yes. > lcFile.c.patch > - during QApplication construction, _XlcLocaleDirName() is called 5 times, >everytime doing exactly the same, so the patch add the obvious caching That should be OK. > imLcIm.c.patch > - this one is definitely not meant to be applied, it's more a proof of >concept patch. The idea is similar to the lcFile.c.patch, this time it's more >complicated. Every time an application starts, it loads the same Compose file >and start analyzing it, generating exactly the same structure. So the patch >basically takes this generated structure, packs it into one piece of memory, >and stores it to a file. Next time instead of generating the structure again, >it's simply mapped into memory and all pointers are corrected if the address >is different. > > Having the whole structure cached also helps with the fact that its >generation is actually done twice for some reason, once when calling >XOpenIM(), once when calling XRegisterIMInstantiateCallback(). > > Could something like that get into the XFree cvs, and what would I have to >change? I have no idea how you handle portability when it comes to stuff like >mmap(), and some of you probably won't like things like fixing the pointers >in the structure or mapping into memory something possibly created by a >different user (the whole things almost looks like an ugly hack, doesn't it ? >;) ). I'll change this one (and the others, if needed) to meet your >requirements. Since some compose files can be large, it might be useful to have a mechanism to "pre-compile" them. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
