said:
>Well there's the answer then. If the INI files are smaller they consume
>less shared memory, so the apps are less likely to run out of shared
>memory and VOILA! your system is more stable.
More stable is relative and there's a lot more to it than just INI file
size. Both my main box and my laptop have INIs of comparable size and the
systems have basically the same OS code - an eclectic mix of Warp4 and
eCS. The laptop runs for months without rebooting. The main box has some
non-obvious issue and runs for at most 10 days. One of these days I might
actually figure out why.
>Steven, how can I look at, or monitor, the shared memory usage? How can
>I determine if I am approaching the "out of shared memory" condition?
Use Theseus or write your own app to uses the same APIs. The APIs are
pretty much undocumented, so it will take you a bit of research to go the
coding route.
What I do is watch free memory. I find that shared memory tends to always
run out at about the same level of free memory. This makes sense because
you can't run out of shared memory until some app runs out of private
memory.
>On my system, none of my icons are
>eligible.
That's probably because most of your icons are custom icons you assigned
to cmd.exe Program objects. This is not likely to be what a typical user
would find. I run a lot of PM apps and I had 100s of KB of extra icons.
>FPos is worth looking at also though the space saving is
>small.
FWIW, I didn't care all that much for the results produced by FPos. I
like my folders orgainized. I guess if I used the Drives object more, it
would find it more useful.
>You mean there's a _reason_ I should upgrade my Warp 4 Fixpak 10?
Oh, there's probably more than one. While no FP is perfect, many of the
issues you have would go away with some updates.
>It's a handy little database.
With little being the operative word. One of the reasons the WPS has all
this complex caching code is because INI file access is slow and the WPS
puts a lot of data into the INIs.
>I've never looked at mSQL -- maybe that
>would be a good alternative?
Almost any of the embedded databases with OS/2 ports would work fine.
INetMail uses a DBF library which seems to work well.
>I've used a file tree occasionally as a
>keyed database, it actually works quite well even if people sneer at it.
Unix folks don't sneer at it. It's a typical paradigm. The original unix
file systems were optimized for fast access to small files with under 5120
bytes being the sweet spot.
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.
