To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=51254
Issue #:|51254
Summary:|psprint/ don't stat all fonts we use on startup ...
|(twice)
Component:|gsl
Version:|680m110
Platform:|Other
URL:|
OS/Version:|All
Status:|NEW
Status whiteboard:|
Keywords:|
Resolution:|
Issue type:|PATCH
Priority:|P3
Subcomponent:|code
Assigned to:|pl
Reported by:|mmeeks
------- Additional comments from [EMAIL PROTECTED] Mon Jun 27 03:03:40 -0700
2005 -------
So - I was just reading another strace log of OO.o startup to try and cut some
fat out of it - and, I noticed some stat storms of all fonts we use.
Background: statting a file _looks_ free on an strace, and any warm profile -
however on a cold start if a file's inode is unlikely to be in memory - then the
1st stat incurs a synchronous seek overhead - ie. about 10ms;
The attached patch bins about 130 (unique) seeks on startup very roughly -
~130ms off cold start time. This is with a bog-standard, low-number-of-fonts
setup. My laptop has some 500 fonts instead & a slower disk so ... ;-)
Anyhow - the patch breaks into 2 bits: [ and this assumes a fontconfig setup
incidentally ]:
a) we were doing a load of stats to write (flush) the font cache - to fill out
the 'timestamp' field in ~/.../pspfontcache. We write the font-cache on load [
that in itself is quite odd - no idea why ]
However - it appears no-one actually ever bothers to -read- this timestamp
information - ie. we just use the directory mtime to work out if we need to
refresh [ a better idea in the fontconfig world would be to use the
fonts.cache-1 timestamp ]
Anyhow - having binned that - I was still seeing each file [ and indeed a great
scad of directories ] being statted eg.
15911 lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=368, ...}) = 0
15911 lstat64("/usr/X11R6", {st_mode=S_IFDIR|0755, st_size=168, ...}) = 0
15911 lstat64("/usr/X11R6/lib", {st_mode=S_IFDIR|0755, st_size=5064, ...}) = 0
15911 lstat64("/usr/X11R6/lib/X11", {st_mode=S_IFDIR|0755, st_size=984, ...}) = 0
15911 lstat64("/usr/X11R6/lib/X11/fonts", {st_mode=S_IFDIR|0755, st_size=352,
...}) = 0
15911 lstat64("/usr/X11R6/lib/X11/fonts/truetype", {st_mode=S_IFDIR|0755,
st_size=2176, ...}) = 0
15911 lstat64("/usr/X11R6/lib/X11/fonts/truetype/luximbi.ttf",
{st_mode=S_IFREG|0644, st_size=69872, ...}) = 0
per-font we used. Of course, most of those stats are seek-free - but the final
stat of the file is not.
Turns out this comes from 'psprint/source/helper/helper.cxx (psp::splitPath)'
which calls: 'normPath' [ as does a chunk of other code in psprint it seems ].
That in turn calls 'realpath' which (quite apart from path-length
considerations) does the above statting action - to try and work out if each
font is in fact a symlink to another font etc.
Of course - this may be necessary ;-) however I suspect it is not; ultimately
psprint is going to have to cope with identical fonts in different-named files,
hard-linking etc. which realpath will not help with.
Hence - IMHO going to all this statting expense is not really worthwhile. I can
see (perhaps) a need to convert ../share/fonts/... type paths into absolute ones
to make eliminating duplicates slightly more efficient perhaps - so I added a
quick hack to detect './' and '~' in paths.
Either way - this hopefully provides a faily substantial reduction in I/O on
cold start.
Comments much appreciated.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
