> How much of an effect does a large resource have on the system? Once my
> resource broke 10,000 bytes, Glue said this:
>
> Resource Name Size Relocs
>
> DOCUMENT_TEXT 10092 471
> Warning: DOCUMENT_TEXT is very large, that is a BAD thing.
>
> I have a lot of fixed strings in there which I'm going to move into a data
> resource, but how important is it that I do it? This app is for the desktop.
>
> Just curious about how the system works as a whole.
GWRepJohnH writes:
> As I understand the system, you're dealing with two different things here.
> All the resources ending in _TEXT are your source code files. These are
> generally easy to get back down to the 4-6K recommended size limit. All you
> do is break that source file into two or more separate files, and voila, that
> resource is reduced. As Lee said though, this isn't a problem for the
> desktop - especially when the resource in question is a source code resource.
> (Can someone in Alameda back me up on this?)
First, let me say that even if you're working on a desktop machine,
the Intel x86 architecture still limits you to 1Mb addressable space,
which as we know is actually only about 640Kb of user space.
GEOS' global heap, from which all memory resources are allocated, comes
out of that 640Kb. Large resources are ALWAYS a bad idea, because they
can lead to greater heap fragmentation and, in general, poorer memory
performance. In GEOS, you ALWAYS want to keep ALL your resources
(code, object, data) to less than 10Kb. In fact, GEOS' swap driver
has been optimized for swapping out blocks of 2-6Kb in size, so that's
why we always recommend that blocks in that range of sizes.
John is correct GOC will create 1 _TEXT source code resource from
each .goc file -- therefore, splitting up your source code into multiple
files will reduce the sizes of your resources.
Splitting up your source code into multiple files will require you to
do some extra work -- purely mechanical, syntax-related things, like
declaring objects as extern if they're referenced in a source code file
but defined in another. To see the rules on how to split up your source
code into multiple files, surf over to www.geoworks.com (Geoworks Home
Page), click on "Developer Relations", then "Technical Support", then
"Downloadable Files", and get the file LRGSORCE.TXT, "Creating Multi-
Source File Goc Applications."
> Putting strings into a data resource - the other matter - is good for two
> reasons. First it allows for easy localization using ResEdit. ResEdit only
> "sees" strings in resources.
Minor clarification: ResEdit can only find strings that live in chunks
inside resources.
> Second, it allows you to manage the size of a
> more critical resource, the fixed size (also called dgroup.) The fixed size
> is the that amount of memory required to run your app that won't be swapped
> around by the memory manager. You see its size in two places. It is the
> second line of the resources table (your snippet above) and is the second
> part of the file size line (eg: file size: 1,234 bytes fixed size: 123
> bytes.) Text strings not in resources will drive the fixed size way up.
> Glue gives you a nasty-gram when fixed size exceeds 1024 bytes.
John is correct again: DGroup is a fixed block that every application
gets automatically. GEOS puts an app's global variables in DGroup, as
well as static local variables, the stack for the process thread, and
all the app's class definitions. Since DGroup is a fixed block, you want
to keep it as small as possible, since it is never swapped out and eats
up available heap space.
So you'll want to put all your strings in their own resource, and not
only that -- you'll want to put each string in its own text chunk.
For an example, assuming you have the OmniGo SDK, see the HPDB sample
application (Appl\SDK_Omni\HPDB\hpdb.goc) -- there's a resource defined
in the .goc file called DialogStringsResource, which shows you how to
set up the resource, and how to assign your text strings to chunks.
Note that you'll also need to declare the strings' resource in your .gp
file -- see hpdb.gp to see how that's done.
Hope this helps.
Regards,
Paul.