said:
>Separately I've heard that the INI cache space is only 4
>MB or 5 MB, and one other developer (Jim Read at UniMaint) has also told
>me of this problem. So, if you've been lax in cleaning up your INI files
>here's an incentive . . .
This is misleading. Since the shared area is a cache, clean or dirty INIs
should not really an issue. Performance may suffer if the cache has too
much turnover, but the cache size should not cause app failures. What
really causes the INI related failures is a combination of defects. Most
apps do not handle running out of shared memory very well and the WPS with
is a heavy user of shared memory seems to leak memory. How much these
defects hurt you depends on a lot of factors.
Crank up Mozilla or Firefox and run it for several days of moderate
browsing and I guarantee you will run out of shared memory. Since this
will be a side effect of of heavy private memory use, restarting the
browser will allow the system to recover and resume normal operations
unless the shared memory failure had a fatal side effect.
>I run CleanIni every day and my system seems more stable. UniMaint
>Repair and CheckIni seldom find anything fixable so I only run them twice
>a month.
Several new INI cleaning tools have appeared in the last year or so.
Those interested in reducing their INI file footprint should look at Rich
Walsh's Iconomize and FPos tools.
>I also got rid of Theseus which turned out to have something to
>do with half my bootups ending in traps -- not a single trap since I
>removed it.
The version of Theseus you were running is ancient, even in OS/2 terms,
and required a device driver. It is not surprising that it had a defect
or two. The current version of Theseus that works with current kernels
does not require a device driver so while it probably still has some
defects, but these are not going to have an effect on bootup.
FWIW, using INI files for large quantities of data has always been bad
idea, as Peter is now discovering. INI files were never intended to hold
large quantities of volatile data. Ignoring the shared memory issues, INI
file read/write operations are slow by design. There's no index so
everything is a linear search.
Regards,
Steven
--
----------------------------------------------------------------------
"Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
----------------------------------------------------------------------
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"postmaster@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 02 |
April |
2005 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
