AmigaOS3.5 (688/968)

From:John S. Burger
Date:24 Jan 2000 at 22:27:02
Subject:Re: Re: Memory usage

From: "John S. Burger" <jsburger@xmission.com>

On or about 23-Jan-00 22:34:30 Kolbj�rn Barmen typed the following words
about "[amigaOS3_5] Re: Memory usage". My reply is thus...

Hi Kolbj�rn,

KB> From: =?ISO-8859-1?Q?Kolbj=F8rn_Barmen?= <kolla@nvg.ntnu.no>

KB> On 23 Jan 2000, John S. Burger wrote:

>> Actually, if I remember correctly it was I that started this thread. The
>> bottom line is that something is different in Fast memory usage from 3.1
>> to
>> 3.5. Booting with the same startup in both 3.1 and 3.5 results in 3.5
>> using
>> 2-3 megs more Fast RAM than 3.1. Weather or not this is a program being
>> run in startup that is not fully compatible with 3.5 or 3.5 itself is
>> what needs to be answered.

KB> Just to get you going, I have 800-900kB you can start with, if compare
KB> old OS3.1 libs/resources with new OS3.5 libs, I bet you can get this
KB> list growing.

KB> ROM update - 100kB (at least, dont know how much is used to
KB> "run" it) workbench.library - 200kB icon.library - 50kB
KB> classes/datatypes - 500kB (roughly 500k more than in OS3.1)

How long have you been using computers? The fact that one version of a file
takes up a certain amount more space on a hard drive does *NOT* mean that
it uses that much more memory when executed.

As far as the first three above, they are new. Their total disk size is
~350K. I doubt that they use anywhere near that much memory when executed.

As far as classes/datatypes are concerned, I had way more of them installed
with 3.1 than I have reinstalled with 3.5.

So, the 800-900K you speak of means almost nothing in this discussion.

KB> Also you havent mentioned wether you have added new harddrives,
KB> reformatted partitions with new blocksize and number of buffer.

Do you intentionally try to be obnoxious? Do you think everyone on this
list is stupid? I didn't mention anything like that because none of that
has occurred. If you would take time to actually read the posts and then at
least try to comprehend what was posted before answering we would all be
better off.

>> It is the same thing with StackAttack. Someone said that the parameters
>> I was using in StackAttack were unreasonable. However, the fact remains
>> that using those "unreasonable" values work just fine with 3.1 and 3.5
>> but with
>> 3.5+BB1 those same values eat gobs of Fast RAM. So, whose fault is it,
>> StackAttack or 3.5/BB1?

KB> You use values for stackattack that is _way_ out of the range
KB> specified as max in the docs:

KB> "If you are still encountering strange/casual/unmotivated GURUs try
KB> increasing ADDSTACK, let's say by 100 or 200 Bytes. I think it is not
KB> necessary/advisable setting MINSTACK to a higher value than 6000."

KB> Now if you had read the docs and done what the author adviced, you
KB> wouldn't have seen "the problem."

KB> The docs does also mention exactly _what_ stackattack patches:

KB> "StackAttack patches CreateProc(), CreateNewProc(), RunCommand() and
KB> SystemTagList() and alters the stack-size passed to them (depending on
KB> what arguments you supply)."

KB> Now you can ask if any of those have been altered from OS3.1 to OS3.5.
KB> I dont know, but I would not be surpriced. The author of stackattack
KB> ofcourse had reasons to advise against setting the stack too high,
KB> perhaps he didnt have the overview on how this would affect the
KB> system. He certainly had no idea how this would affect a OS3.5 based
KB> system.

Of course he wouldn't know because it doesn't happen with 3.1. That is why
I asked the question.

John



*Thor - US Registration Site - WebVision*

This message was composed on *24-Jan-0 15:01:40 MST*
Via Thor V2.6a
mailto:jsburger@xmission.com http://www.xmission.com/~jsburger

CA bumper sticker: Cover me, I'm changing lanes.

--------------------------- ONElist Sponsor ----------------------------

Accurate impartial advice on everything from laptops to table saws.
<a href=" http://clickme.onelist.com/ad/Productopia ">Click Here</a>

------------------------------------------------------------------------