Oct 11, 2022 – The Next Step
Aug 30, 2022 – The Last Word
Jun 01, 2022 – A Helix Hero moves on
Dec 31, 2021 – 2021 Final Dispatch
May 04, 2021 – A small step out of line (Helix 8.0.1)
Nov 03, 2020 – Omne trium perfectum (Helix 8.0.1)
Dec 21, 2019 – Train to the Future (Helix 8.0)
Jul 02, 2019 – Step right up (Helix 8.0 Test)
Jan 02, 2019 – Have we seen our darkest hour?
Jan 01, 2018 – Helix 7.0.4: Features and Fixes
Oct 24, 2017 – Help Is Here: Riding the Helix Express
Sep 26, 2017 – Helix 7.0.3: Features and Fixes
Apr 29, 2017 – Helix 7.0.2: Features, Performance, Bug Fixes
Jan 20, 2017 – Helix 7.0.1: Performance Update
Dec 20, 2016 – Helix 7.0 is Here
Sep 27, 2016 – Third Time a Charm?
Sep 12, 2016 – The Point of No Return, Pt. 2.
Aug 31, 2016 – The Point of No Return
Mar 31, 2016 – A Mythic Day Is Now Upon Us
Dec 8, 2015 – Louder and Hopefully Clearer
Oct 21, 2015 – Back To The Future
May 01, 2015 – May Day
Dec 31, 2014 – Final 2014 Frontier Dispatch
Aug 18, 2014 – Open Hand
Jun 19, 2014 – Helix 6.2.4: Stability, Speed and Things to Come
Apr 25, 2014 – Helix 6.2.3: Event, Acquired
Mar 05, 2014 – The Feature Game, 2014 Edition
Jan 06, 2014 – Helix 6.2.2: Mavericks and More
Dec 19, 2013 – 43 Days of Anticipation
Nov 06, 2013 – Helix 6.2.1: Family Reunion
Sep 26, 2013 – Helix Client Preview #3
Sep 04, 2013 – Helix Client Preview #2
Aug 15, 2013 – Helix Client Preview #1
Jun 10, 2013 – Europa: Helix RADE 6.2 Ships
May 10, 2013 – PR23
Europa: Of Users and ‘Users’
Apr 17, 2013 – PR22
Europa: Fixing the Fix
Apr 11, 2013 – PR22
Europa: Fonts and Other Fixes
Mar 12, 2013 – PR21
Europa: Point, Click and Drag
Feb 13, 2013 – PR20
Europa: Ascending Mt. Abacus
Jan 17, 2013 – PR19
Europa: Template Phase Three
Dec 31, 2012 – PR18
Europa: The ‘Useable’ Template
Dec 10, 2012 – A Good Delay
Nov 14, 2012 – PR17
Europa: From Sandy Shores
Oct 10, 2012 – PR16
Europa: Two Old Puzzle Pieces
Sep 14, 2012 – PR15
Europa: The Sliver Lining
Aug 10, 2012 – PR14
Europa: Something You’ll Like
Jul 11, 2012 – PR13
Europa: The Lion Sleeps Easier
Jun 11, 2012 – Europa Pioneer Plan, Year Two
Jun 08, 2012 – PR12
Europa: A Late Spring Snowstorm
May 10, 2012 – Europa: High Noon at the Oasis
Apr 10, 2012 – PR11
Europa: Get Out Your Umbrellas
Mar 10, 2012 – PR10
Europa: The Sleeper Awakens
Feb 10, 2012 – PR9
Europa: Enormous News
Jan 16, 2012 – PR8
Europa: Deleting the Undeletable
Jan 10, 2012 – What It All Means, Somewhat Belatedly
Dec 10, 2011 – PR7
Europa: Sound Restored…
Nov 22, 2011 – Helix 6.1.10: Some Unfinished Business
Nov 11, 2011 – Fear and Loathing in Europa-Land
Nov 10, 2011 – PR6
Europa: Resist the Amygdala
Oct 10, 2011 – PR5
Europa: AppleScript Nirvana
Sep 10, 2011 – PR4
Europa: Changes All Over
Aug 10, 2011 – PR3
Europa: Of Views and Users
Aug 03, 2011 – Helix 6.1.9: Trapped Like Rats
Jul 10, 2011 – PR2
Europa: Never On Sunday?
Jun 10, 2011 – PR1
Europa: Right This Way
Feb 21, 2011
Helix 6.1.8: Don’t Panic
Dec 31, 2010
Learning AppleScript with Helix & the Helix RADE Readiness Kit
Sep 17, 2010
Helix 6.1.7: A Cloud the Size of a Man’s Fist
Jul 27, 2010
Helix 6.1.6: Running At Last
Dec 31, 2009
Something’s Going to Happen…
Dec 07, 2009
Untying the Gordian Knot of Helix Performance
Nov 30, 2009
Helix 6.1.5: Crossing back over the line
Aug 31, 2009
Helix 6.1.4, RADE and 6.1.5
May 04, 2009
Helix 6.1.3: Between Observations of Radio Silence
Dec 31, 2008
Elegance, Simplicity, Complexity and Reality
Nov 11, 2008
Measuring Time in “Classic-Free Days”
Sep 05, 2008
Someday Soon, Your Prints Will Come
Jul 25, 2008
Survey: Where Do We Focus Next? (Candygram)
Jul 11, 2008
Helix 6.1.2: Detours & Speed Bumps
Jun 30, 2008
Helix 6.1.1: Unsung Heros, Summer Snow and Low-Hanging Fruit
May 19, 2008
Relief for “Universal” suffering…
Mar 31, 2008
Server 6.1: Coincidentally, There Were These Phone Calls…
Dec 31, 2007
Engine 6.1: It Sure Took Long Enough…
Dec 14, 2007
I am a Helix User…
Nov 19, 2007
Tiptoe on the Limbs…
Oct 19, 2007
A Vision of Self-Sufficiency…
Sep 08, 2007
We Interrupt This Silence…
Jun 22, 2007
River Deep, Mountain High
May 16, 2007
Before the Fun Begins…
Jan 13, 2007
All I Want Is You [Helix]
Dec 31, 2006
The Other Helix “Wish List”
Aug 29, 2006
Slipping Through the Cracks
Aug 10, 2006
The Little Engine That Can
Jul 03, 2006
Channel Surfing for Helix Users
May 26, 2006
The Tale of Components C & D
Dec 19, 2005
We interrupt our myth-busting…
Nov 10 2005
Debunking Myths of the New Age of Helix (Myths: Part 2)
Sep 21 2005
Don't let Helix keep you from macOS (Myths: Part 1)
Jul 28 2005
Let's talk about Helix prices…
Jun 08 2005
Taking the wraps off Pele
Mar 11 2005
Volcanic Dreams of the Wild Optimists
Jan 31 2005
Helix 5.3.1 Fixes TCP/IP Disconnect Bug
Dec 24. 2004
A Helix Christmas Carol
Dec 04, 2004
Helix 5.3 is here
Sep 27, 2004
What's in a name?
Jul 14, 2004
Pinocchio becomes a real boy
Jun 11, 2004
HelixChat Goes Live
Apr 21, 2004
Recovery Team Expedition 2004: Trail Report from Route 67
Feb 17, 2004
Chaski to relieve suffering for Helix TCP/IP users
Dec 31, 2003
Nov 29, 2003
How precious to communicate
Sep 01, 2003
O/R Status Report
Aug 08, 2003
A bullet is dodged…
Jul 14, 2003
Paid Services and Helix Maintenance Manager introduced
Jun 09, 2003
Helix 5.2 Announcement
May 29, 2003
One look back and two extreme looks ahead
May 03, 2003
In Memoriam: David Lee Harmon
Apr 21, 2003
We interrupt this program…
Apr 07, 2003
The Forums are Open
Mar 03, 2003
Helix Nemesis Returns
Jan 23, 2003
More notes from the marketing blotter
Jan 08, 2003
Helix Education Returns
Dec 30, 2002
Helix 6 gets underway
Dec 20, 2002
Dec 15, 2002
Let's Talk About Our Future
Dec 09, 2002
5.1 (almost) Final Beta is Testing
Nov 21, 2002
Down to the Crossroads Again
Oct 21, 2002
Have you seen this screen?
Sep 25, 2002
Notes from the Marketing Blotter
Sep 05, 2002
Seven Minutes in Helix Heaven?
Aug 22, 2002
Is there a doctor in the house?
Aug 08, 2002
0.00018461538% and Musings on the Nature of Helix Martyrdom
Jul 15, 2002
Making Up the Rules As We Go Along
Jul 02, 2002
Dialogs in the Rough
Jun 24, 2002
What Price Helix Morality?
Jun 17, 2002
Why Are We (Still) Here?
Jun 10, 2002
Sep 16, 1997
In Memoriam: Jonathan Schneider
Have you seen this screen?
21 October 2002--As noted last time, were going to shift gears a bit with this posting and talk about a subject near and dear to our hearts...how to manage memory in Helix 5.
Since this experiment began back in June, weve made every effort to solve each technical problem presented to us in a timely and effective manner. A few times in the past few months, weve encountered situations where the lack of comprehensive or definitive information about this memory management has resulted in, to be generous, a less-than-satisfying experience for some Helix users. It appears that, in spite of the availability of rather profuse documentation on the subject, these users either have not seen, or just cant figure out what to do when they find their way to the Memory Preferences dialog depicted above.
Too often, when faced with a new feature or a change to an old feature, theres a tendency on the part of users to attempt to apply old knowledge to new problems. The rules have changed in Helix 5 and you need to look at memory management issues through new eyes. This is our first--and hopefully only--proactive attempt to explain what these differences mean on a practical level. Before moving into the discussion, we need to point out that there are three major obstacles to creating the aforementioned, much-needed comprehensive or definitive information, illustrated by the three obviously ridiculous questions that follow:
Obstacle #1: Why cant everyone be just the same as everyone else?
Helix users seem to come from nearly every walk of life, and their knowledge levels range from novice to know-it-all. And be they developers, end-users, business users, personal users, network clients or technicians, their levels of expertise never seem to correlate with their system- or Collection-maintenance habits. (This is a nice way of saying that there are still too many supposedly well-informed people who fail to keep their systems in optimal condition, run the Helix utility programs or even back up their work.)
Occasionally, we have the added burden of dealing with the inability or unwillingness on the part of a few people to provide us with real email return addresses or telephone numbers. [You know who you are. So do we, and we want to help, but youve got to give us a way to reach you. Why put us to work for you if you dont want to know whats crashing your Collection?]
Obstacle #2: Why cant there be just one simple Helix Collection?
If all this diversity didnt make Helix Technical Support difficult enough, there is the absolutely inalienable fact--and this cant be emphasized strongly enough--that no two Collections are alike.
This can even be said for a Collection that is duplicated from another one. Two seemingly identical Collections may certainly have different amounts of data in them. Two Collections of exactly the same size might have vastly different structural components. And when we talk about structural complexity, theres no simple rule of thumb to determine what that term means. There are Collections smaller than a megabyte that are structurally more complex than those many times larger. And structural complexity is not necessarily merely a function of how many relations are found within a Collection.
Obstacle #3: Why cant everyone just use exactly the same computer?
The situation is further exacerbated by the practically limitless vista of hardware configurations. Each computer has a CPU, a hard drive, some amount of memory, user settings that are almost always in a state of flux and an infinite variety of @&#$ installed in their system folders. Is your Collection running in a RAM disk? Is it on an NT server? And then theres the networking issues. Are you on Ethernet or LocalTalk wiring? Are you using AppleTalk or TCP/IP?
Why, you may well ask, do we point all this out?
What does it all have to do with managing memory in Helix 5?
Well, there are, sadly, no hard and fast rules that can be applied to the great diversity of Helix situations. However, and in keeping with our theme of attempting to be very general, there are three areas that you as a user must be responsible for managing. These are:
Responsibility #1. Your knowledge of Helix and how best to use the tools it provides.
This is a subject far too vast to ever be covered on a single web page. The sheer diversity of applications makes it virtually impossible to create a single volume that adequately conveys how to use Helix. We hope it wont be too much longer before we can resume Helix training. Until then, folks, youre on your own here. Fortunately for most of you, Helix is forgiving enough to let you get away with almost anything you can concoct.
Responsibility #2. How your hardware and software are maintained
A section of our Helix Reference (available as a free download from this web site) offers very smart guidelines about this. If you arent doing at least what is recommended therein, you should probably be ashamed of yourselves...especially when your Collection cracks and you have no backups.
Responsibility #3. The amount of memory they apply to their Helix application and how to optimally allocate that memory.
Today, were going to focus on this one because the information in our Helix Reference is admittedly long on technical and short on procedural. Clearly more of you seem to be reading whats written here than reading the Helix Reference, so as long as weve got you for a little while, were going to strike while the iron is hot. And even though we can only offer--at best--some very general guidelines, the increased incidence of calls about this issue of late has caused us hop off our 5.0.3 and macOS development cycles for a moment and attempt to clear up some common misconceptions about memory management in Helix 5.
Lets begin with the most frequently asked question:
Do I Have To Use These Features?
I Mean, What If I Just Ignore That Screen?
OK. Suppose you just download 5.0.x and install it, crank the RAM up to where you last had it and go back to work. Is there a downside to this?
All things being equal, everything should work, memory-wise, about the way it worked in 4.5.5 or whatever you were using before you upgraded. Actually, prior to this version of Helix, when you increased the RAM allocation to a Helix application in the Finder, Helix simply divided that additional RAM between its own internally-managed Data and Structure caches. For those of you who have delved deeper into this subject in the past, we know its much more complicated than that, but remember, the purpose of this discussion is to arrive at some very general guidelines.
The downside is simple: youre not taking advantage of one of the key features of the Helix 5 product line. You paid for your upgrade and youre ignoring a potentially powerful tool that could considerably lighten your workload.
OK. Alright. Where Is This Screen and How Does It Work?
As noted above, were going to attempt to create some very general rules. Were going to call them the "General Rules of RAMJet()" and well start, as the Marx Brothers would say, with the first number:
1st General Rule of RAMJet: Turn off Virtual Memory
Sorry folks. Go out and buy yourself some real RAM. The price of computer memory right now is about as low as it will ever get. If you havent maxed out the RAM on your computer, theres probably no better time than NOW to fill those empty slots.
That seemingly small detail has surfaced in a number of calls, and unless you have VM off, none of the rest of this discussion will make any sense. If you must use some application that requires VM to be on, use it either on another machine or when Helix is not being used.
2nd General Rule of RAMJet: Turn AutoSave On and Save and Clear Caches Off.
AutoSave OFF is BAD. Make sure its ON. While in that dialog, make sure Save and Clear Caches is OFF. If youre using a Data cache, why would you want to clear it out after saving?
3rd General Rule of RAMJet: Know Where It Is
Four Helix applications have Memory Preferences: RADE, Server, Engine and the Helix Utility. You arrive at the screen above by selecting "Preferences" from the Edit menu or by typing command-semicolon when in any of these applications. Note that in RADE, the "Preferences" menu item is deletable from a User menu. Therefore, you may restrict access to this function if your collection design requires removing this command. In that situation, it will only be available in RADE when in Design Mode.
The most dramatic performance improvements generally seen--and this is based strictly on anecdotal evidence--is in the use of the Helix Utility. Users with enough RAM to get maximum benefit from this feature have reported that Collections that used to take an hour to run through the Helix Utility now run in under 10 minutes, some in under 5. Thats a pretty significant improvement. Whether we like it or not, one of the big sins frequently committed by Helix users is not running the Helix Utility often enough and one of the principal reasons given in informal surveys of why they dont is that it takes so long to run.
Later, youre going to learn about certain kinds of Helix errors that address Data and Structural memory caching. If you should see one of these errors while using Helix Client, or Helix Update Collection, which do not have Memory Preference settings, increase the amount of memory you allocate to these applications in the Finder.
4th General Rule of RAMJet: To use RAMJet, the Custom Caches must be On
Where is the improvement coming from? Custom Caches or RAMJet? By now, the name we have given our rules should give you the answer.
You really dont have much of a choice about this. You cant use the Data and Structure caches separately or exclusively. Turning on one turns on both. And without these, RAMJet cannot be turned on.
There are rare instances where it might make sense for you to adjust the size of the Data Cache. Some operations, for example, require that the Data cache be of a certain size (the exact numbers depend on multiple factors: number of records, number of Fields in records, total size of record data, number of Relations involved in the action, etc.) so setting it to its minimum value can sometimes result in 5xxx errors (more about which below). In these cases it is necessary to increase the data cache. You should view this as a concession, not an improvement. Having a smaller Data cache is better than having to have a larger Data cache. Sometimes the larger cache is unavoidable, but no less regrettable.
Generally speaking, however, the Data cache will always fill to overflowing and there’s nothing you can do about it. No matter what you do, it will always fill to a point where there is around 72K free (this number may vary).
The purpose of the Data cache is to speed Helix by keeping recently read data in RAM, avoiding disk access. If youre going to use RAMJet, the Data cache is redundant and pointless. It should be kept out of the way as much as possible. The best approach is to minimize the delay and effect by keeping the data cache as small as possible.
At the risk of oversimplifying this, most often, increasing the size of the Data cache is like putting a larger bandage on a bleeding wound. Itll keep blood from dripping on the floor sooner, but eventually, the patient will still bleed to death if the bleeding doesnt stop.
5th General Rule of RAMJet: Start Small and Work Your Way Up
When you first enable the Caches and turn on RAMJet, try to ignore your inner voice, in particular the one telling you to crank up the cache settings. We say this in part because when you do eventually call for help, were going to ask if you tried this.
Since the Data cache setting is for the most part irrelevant, our advice is to start by leaving the custom caches at their default settings. Start low and observe the error codes. If you get 7xxx errors, increase the structure cache (in 2 MB increments). If you get 5xxx errors, increase the data cache (in 1 MB increments). If either problem persists beyond a doubling of the default settings, stop what youre doing and call technical support.
Now if you absolutely do know it all and you want to get any deeper into this, you should start by making periodic inspections of the Server Info screen during the day. Both caches will fill as the day goes on. The Structure cache needs to be set large enough that it never becomes completely full. We recommend keeping it large enough so there is always 1,000-2,000K of free space. And keep in mind that a good network administrator will keep an eye on changes to the size of the Collection over time and make appropriate adjustments so that the amount of overall RAM devoted to their Helix RADE or Server provides an adequate ceiling as the Collection grows.
6th General Rule of RAMJet: Unless you have enough real RAM to get your entire Collection into RAM, you will probably not derive maximum benefit from the use of this feature.
If you have a small Collection and more than enough RAM, you are probably not having speed and performance issues that would drive you to experiment with custom cache and RAMJet functions, even in The Helix Utility.
However, a significant number of Helix users have been using Helix for years and years and have Collections that have grown extremely large. Some of these users--and you know who you are--cant seem to bring themselves to part with any of their information so their Collections never achieve any kind of size stability and just keep on growing. These Collections would probably benefit most from the use of custom caches and RAMJet, provided, of course, that the machines are expandable to the amount of RAM needed and that someone actually buys and installs it. Remember what we said earlier about the price of memory!
Having said this, let us not discourage you from using RAMJet if you dont have enough RAM to totally enclose your Collection. Plenty of users have reported that the Helix Utility runs much faster than before on the same size Collection even though they dont have nearly enough RAM to get the whole thing in there. Just make sure that when you try it, do it on a Collection you have properly tested and backed up.
7th General Rule of RAMJet: Performance and Stability are NOT directly proportional
This statement of cold, cruel fact is a rule that must be respected. To illustrate its importance, we offer this graphic:
Theres almost always a trade-off between performance and stability. The faster you drive, the less control you have over your car. As you increase memory allocations you increase stability (to a point) and you decrease performance (again, to a point).
Obviously, too little memory causes problems of its own. but once you’ve gotten past the 'memory starved' situation of, for example, a 200 MB Collection running on Helix Server with 20 MB allocated, you then face the foggy world of not knowing where the perfect settings are.
Each type of memory (OS, Helix application, RAMJet, Structure cache, Data cache, plus other internal caches) has its own pair of curves, where too little or too much is bad. In between too little and too much is a pretty wide range of acceptable or "workable" values and "just right" is at some unknown spot in between. Because each memory type has its own curve, getting the settings right for one parameter might move another into a danger zone. Finding the compromise that allows everything to function acceptably is the hard part.
One of the purposes of RAMJet feature, besides the obvious RAM disk emulation, is that it gives you control over the Structure and Data caches. The larger and more complex the Collection, the longer the battle will be to find the set of values for your Collection. Working to get those settings optimized is WORK, but in all but the rarest of cases, persistence will pay off.
Bottom line question: How much RAM do I allocate to my Helix application in the Finder?
Depending upon the Helix application youre using (e.g., Helix RADE, Helix Server, etc.), Get Info in the Finder and find out what the minimum memory requirement is for that application. To this number, add the total of your custom caches plus the size of your Collection and then add another 10% or so to give it some breathing room, both for during the day as it uses memory, and over time as it grows in size.