Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!swrinde!news.dell.com!tadpole.com!uunet!somnet.sandia.gov!elam.mdl.sandia.gov!aflundi From: aflundi@sandia.gov (Alan F Lundin) Subject: Re: Where are the lib??.sa.?.? files in FreeBSD 1.1.5? Message-ID: <1994Jul12.150452.21113@sandia.gov> Reply-To: aflundi@sandia.gov (Alan F Lundin) Organization: MDL, Sandia National Labs., Albuquerque, NM References: <1994Jul7.220203.8632@sandia.gov> <JKH.94Jul8011514@whisker.hubbard.ie> Date: Tue, 12 Jul 1994 15:04:52 GMT Lines: 69 In article <JKH.94Jul8011514@whisker.hubbard.ie>, Jordan Hubbard <jkh@whisker.hubbard.ie> wrote: >In article <1994Jul7.220203.8632@sandia.gov> aflundi@sandia.gov (Alan F Lundin) writes: > > I loaded ispell from the FreeBSD packages-1.1 > directory and was surprised to see how long > it took to get started (16 sec versus about > 7 sec on a Sun LX). Does this have any thing > >Save version of ispell, I presume? No, on checking I found Version 3.1.08 on the Sun using /usr/dict/words+web2 for dicts and a "strings" on packages-1.1/ispell_bin.tgz shows version 3.1.03 in a copyright comment. I haven't yet tried to analyse the hashing in ispell (I presume there is just a straight-forward hash used as an index into the .hash files), but on the Sun, I have one combined hash file that is 577,896 bytes, and I see that there are two .hash files in the ispell package that are each 4,556,688 bytes. Perhaps the hash size is the reason for the differences as well as two hash lookups, instead of just one on the Sun. > How much memory on each machine? 16M with a 486/33 for FreeBSD 1.1.5R, and 32M with a SunLX running SunOS4.1.3_U2. I don't think either is paging though. > to do with excessive copy-on-write paging due > to a lack of shared lib .sa. files? Are the > >What makes you think that the lack of .sa files causes a lot of extra >COW operatings under FreeBSD? I'd like to see some stats please! I don't know that there are lots of extra COWs (I don't have any stats). I was just hoping to learn something about the shared lib implementation. If the .sa.'able data isn't put into the executable, doesn't there have to be at least one COW for each page in the shared lib containing that data (vs none when that data is in the executable)? And if that data is sprinkled sparsely though out the share lib, wouldn't you get an excess of data COWed? I'm not accusing, just asking, because I really don't know. > "silly archives" (is using .sa. files now > obselete)? > >They are in certain implementations. I don't see as they're a >necessity, if you handle your resolution of global data properly. If proper global resolution doesn't mean grouping the writable global data together, could you point me to something that I can study (source and/or docs) to understand what you mean? Thanks (and many thanks to the core team and other contributors for putting together such a terrific OS!). --alan -- Alan Lundin <aflundi@sandia.gov>