[futurebasic] Re: A New Word Order - semi-intelligent answers to your questions

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : November 2003 : Group Archive : Group : All Groups

From: Ken Shmidheiser <kshmidheiser@...>
Date: Fri, 31 Oct 2003 20:52:50 -0500
Dennis wrote:

---snip---

>2. Computer type: PPC 5400, OS 9.1, using Sonnett Crescendo G3
>3. How much RAM:
>      Built In - 48 MB
>      Virtual Memory - 60 MB
>      Unused RAM 36.7 MB
>      FB^3 - 5.9 MB
>      OS - 16 MB
>
---snip---

Dennis,

Your problem jumps off the page:

You simply don't have enough horsepower-- read as real RAM-- with 
this configuration to handle the huge dynamic arrays Wordexer is 
capable of creating with large text files, particularly when trying 
to run it from within FB.

(The core code was developed for Carbon on a B&W G3 with 896 MB real 
RAM in OS X 10.2.8. I must apologize for my arrogance in assuming 
that everyone who tried to run it would have that kind of memory. The 
code glaringly includes no error checking for available memory.)

Do this test:

Use FB to build the PPC app, then do a "Get Info" on the built app an 
check the memory allocation:

Suggested Size  37761 KB
Minimum Size:   25174 KB
Preferred Size: 37761 KB

You only have 48 MB of actual RAM, so when running Wordexer 
full-bore, you have only about 10 MB left to run OS 9.1 and whatever 
extensions/fonts/files/and/or applications that are open.

When you try to run the code from within FB, you have to subtract 
almost 6 MBs that FB consumes from the 10 MB remaining free on your 
machine, leaving you only 4 MB in which to run the OS!

----------------------
Total 5400 RAM:  48 MB
----------------------
Wordexer code:  -38 MB
FB overhead:    - 6 MB
----------------------
      Subtotal:  -44 MB
----------------------
Available for OS  4 MB <--- Major crash time!
----------------------

Shades of System 7.0!

Even your virtual memory is minimal-- particularly if the virtual 
memory space is not contiguous on the disk-- a sure recipe for a 
crash. (I would not be surprised that when your MAC ran out of RAM 
memory and flipped over to virtual memory on the hard drive, then ran 
out of space there and crashed, that code fragments were left 
scattered all over the drive, thus preventing future runs in FB. You 
probably need to defragment your drive to reclaim the lost space and 
optimize Virtual memory once again. One caveat: Virtual memory is 
painfully slow in Classic.)

With this configuration you will never be able to index the Bible.

Since you are a teacher, I assume you have several Macs for your 145 
students. Unless your school made the foolish mistake of purchasing 
the 5400s with 8 MB RAM chips (since 1984 I've seen this scenario 
repeated over and over in our local school systems), you might be 
able to temporarily "borrow" some RAM from some of the other machines 
to give your 5400 enough memory to breathe. (I may even have some 
extra RAM around here for a 5400 in my parts box, although I don't 
have much for anything earlier than a 7500, with the exception of a 
bunch of 32-pin Classic chips.)

Another option is to reduce the code's internal memory overhead, 
albeit at the cost of being able to work with only small text files.

At the very top of the code:



Include "Subs PrefsFile.Incl"
include "Subs PollTime.Incl"
// For older systems As per Robert Purves

Dim System 25000000



that last statement "Dim System 25000000" forces FB to allocate 25 MB 
in RAM when Wordexer is compiled-- and that doesn't count FB's own 
overhead. Try REMming out the line, and from within FB test to see 
how large a file you can work with. Begin with something small, maybe 
a copy of this post, and work your up to find the largest file size 
you can handle without a crash.

Another way to reclaim some space is to REM out this line (found 
right after the Globals):


// to speed up dynamic array operations
gFBDynamicGrowInc = 1000


This line tells FB to grow its dynamic arrays 1000 elements at a time 
as a way to increase speed. Removing the line will force the array 
elements to grow in increments of 10 at a time which will reduce the 
app's speed, but which also will make a dent in memory allocation in 
your particularly tight situation.

Unless you are running very basic applications, I assume you must 
struggle with memory shortages all the time on this machine.

I hope these suggestions prove helpful.

Let me know what happens.


Ken


p.s. Kudos to you for sharing FB with your students!