Helix 6.1.6, walking and running

27 July 2010 — There’s a moment early in the movie “Avatar” when Jake Sully, a wheelchair-bound soldier, first awakens in his “new body,” able to walk for the first time in as long as he can remember. But Jake’s excitement with walking is short-lived. He wants to run, and when he can finally sprint again, it is an exhilarating experience.

Helix users can relate to both the pain of “lost abilities” when there was no macOS native Helix at all, and the joy of finally being able to “walk” when the first macOS Client and Engine were released. But that bliss was short lived as users grew impatient with its inability to run.

While walking and running (or in this case, functioning and performing) may seem similar, they involve completely different sets of skills and create different kinds of stresses on supporting structures. The common thread is that you can’t run until you can walk so that’s the course we plotted to get Helix into macOS.

Versions 6.1 through 6.1.5 were all about walking — which we defined as getting Helix to perform its functions without crashing.

When 6.1.5 was released, we were finally satisfied that we had Helix products that provided all the functionality we had promised to deliver and were stable enough for our customers to use if they were brave enough to take the plunge. But no sooner had we revealed our plans for Helix RADE when the feedback started: users were only interested in seeing RADE learn to walk once we had successfully taught the Helix Client and Engine to run!

And so, having announced the Europa project on December 31, 2009, we were obliged to move work on RADE to a back burner. Progress on RADE did continue (more about which next time), but the start of 2010 saw our efforts focused primarily on macOS interface performance.

The fruits of those labors may at last be picked

Helix 6.1.6 ships today.

Our principal objective in spending the past seven months working on Helix 6.1.6 was to produce products that would, once and for all, allow Helix users to abandon Classic and move on. That would require improving the overall performance of the macOS Engine and Client to the level of the same products in Classic Helix.

Although there remain a few things that may inevitably be faster in Classic, we knew the experience of using Helix in macOS could be made as comfortable as that of using Helix in Classic. That was where we set the bar.

Reaching it required solving several complex and convoluted mysteries. When you finally solve a mystery, the solution always appears simple and logical in hindsight. But even if we had known the answers before we started, almost every step forward was thwarted by the recurrence of some other problem that had already been resolved at least once before. In retrospect, that’s what made it take so long.

Helix 6.1.6 brings performance up to the standard we hoped for and thus marks the end of the Preview Release phase for Engine and Client. They are at long-last full-fledged macOS products like Helix Server and our diagnostic tools. We hope you’ll be as pleased with them as we are.

More than just speed

While this edition of The Latest Word speaks primarily of performance improvements, that’s not all Helix 6.1.6 is about.

We also spent time fixing bugs and polishing and enhancing features, so the list of changes in Helix 6.1.6 goes far beyond simply a faster Helix. When you visit the Helix 6.1 product page, be sure to take some time to read the lists of bug fixes, enhancements, etc., so you are fully aware of everything Helix 6.1.6 has to offer over its predecessors.

Bearing in mind that some aspects of moving Helix to macOS required us to change functionality in several areas, we knew from the outset that as we moved further and further forward, it would be more and more difficult to truly compare "apples to apples."

In Classic, for instance, a dynamic popup was limited to 253 entries. In macOS, that limit has gone away, and that popup populates very quickly; you tab and before you can even click it, all the records are there. And you can scroll through a popup list of thousands of items even faster than you can the 253 in Classic. Every little change like this one adds up to an improved experience. And as we move forward in RADE, much more of that experience will improve.

Ultimately, we had to do some time testing to assess more objectively just what kind of job we actually did in those seven months. So here we are. As the first two charts on the right show, versions 6.1.3–6.1.5 (collectively referred to as 6.1.5) were, for the most part, considerably slower than Classic Helix. Lists in particular were troublesome, with the PowerPC version being up to 10x slower. A list that could scroll in less than a second per page in Classic was taking nearly seven seconds per page on PowerPC (and about 1.5 seconds on Intel).

But as the charts show, all of that has changed. The first chart compares the relative speed of working on List views. To say that lists are “faster” than in Helix 6.1.6 is like saying a stretch limo is “bigger” than a Yugo. That same list that took nearly seven seconds per page in PowerPC Helix 6.1.5 takes less than half a second per page in PowerPC Helix 6.1.6. That’s fourteen times faster! Words do not do it justice.

The second chart compares the relative speed of working on Entry views in Helix 6.1.6 as compared to 6.1.5. The Intel native Helix is twice as fast as before, and the PowerPC version is nearly ten times faster! Even the Classic Client is twice as fast as it was before.

The entry view used in these tests is a fairly complex form we use for beta reporting. It contains 85 rectangles altogether. 34 of them are data rectangles, and of those, 9 are dynamic popup menus. And our tests use Helix Client because performance problems are amplified when running across a network. In other words, in no way could this be considered a ‘best case’ test.

Classic vs PowerPC vs Intel: 6.1.6 Head to Head

The purpose of the above charts was to show that Helix 6.1.6 is faster than its predecessors, but a more vital question is: how do the various native versions compare with each other? This chart illustrates the vast improvement of Helix vis à vis Classic. You can see that the Intel-native Client is about twice as fast as its Classic counterpart, and though the PowerPC version is a bit slower when dealing with lists, it too is quite a bit faster than Classic at handling entry views. When it comes to data entry, macOS native Helix is just plain faster than Classic.

With prior versions we recommended that if you used a PowerPC Mac you should continue to use the Classic Client. That advice is now obsolete. Helix Client 6.1.6 running on a PowerPC Mac is nearly twice as fast as its Classic counterpart.

There are still a few types of form construction where Classic is faster, but there are easily implementable workarounds for many of those constructions and this version addresses the vast majority of cases and actually makes working in macOS quite enjoyable.

Adventures on the torture test track

At various points in the performance-enhancement phase, we had to stop and ask ourselves whether or not additional work on any particular aspect would pay enough benefits to make the time spent worth it. Remember: everything we do here is in some way part of a race against time. Old machines are dying off and the new ones do not run Classic.

During this work we also discovered ways to make Helix even faster, but implementing them now would have set development back even further, and in light of the performance gains we were seeing, we elected to attempt those changes later on. Because we work with these products many hours every day, we have become quite well adjusted to the new ways Helix works. It is our hope that you will all attain that same comfort level with these new products.

In testing Helix performance, several so-called torture tests have become part of our routine. One is a routine that was created back in the Odesta days.

At the top of almost every Helix wish list has always been a way to display text in a list without having to create list rectangles large enough to display the longest record in that list. In the Odesta routine, Helix would slice up a bunch of text records into lines and present them as a list, which accomplished the desired result, but was too slow to be of any use to anyone, taking close to fifteen minutes to complete on a Mac Plus.

Helix 6.1.6 runs that routine in a flash. In three or four seconds on a PowerPC, it beats Classic by more than 65%. Lists in general are fast. And you can scroll through them easily, using the mouse, the home/end/pageup/pagedown keys, or even a scrollwheel/trackpad.

And although the performance of lists with more than one subform is vastly improved over 6.1.5, embedded subforms remain a problem. Embedded subforms are typically used by various Helix calendar constructions, where designers have long used embedded subforms within each calendar date to allow a user to not just to see how many things are slated for that date, but to be able to double-click them open right there.

When we began working on 6.1.6, a typical calendar constructed in this manner could take upwards of 3 minutes to draw on a PowerPC. Today, that’s down to around 23 seconds, but that may still be too long for you. The simple and logical workaround for the calendar is to build it only one level deep, and create an subcount abacus inside each day’s rectangle that indicates how many items are on that day’s schedule. Then if you really need to see them, you can double-click open the date, and display them all as a list. This minor adjustment actually solves two problems: the performance issue and the problem when a day has so many entries that it ‘spills over’ and creates a second instance of the same day, throwing the calendar out of whack.

Learning to love the new Helix, warts and all

It is said that “One man’s trash is another man’s treasure.” You never can predict accurately whether a particular change in behavior will resonate with users or drive them to distraction until they’ve had a chance to use it. Our intrepid beta testing crew was initially aghast, for instance, when they saw the way Helix 6.1.6 displayed forms as they were updating. A side-effect of Helix 6.1.6’s new multi-threaded view drawing means that the data for a form may not arrive in a logical, top-down order. To identify fields where the new data has not yet arrived, a gray-and-white checkerboard pattern overlays any rectangles where data changes are still pending.

This new look essentially replaces the Classic spinning wrist watch cursor, and provides a much easier way to identify which data is changing. How many times have you seen a view ‘flicker’ as data changed, but could not readily spot which data had changed? Although the new overlay pattern is ‘jarring’ at first, once you get used to it, you come to appreciate the additional feedback it provides.

Another new behavior that requires a period of adjustment is that some lists open up and appear to be doing nothing at all at first, but then, suddenly, the data bursts onto the screen. From a cold numerical analysis, these lists are performing much faster than ever, in many cases much faster than they would in Classic, but the effect of the initial delay is to give the perception that it is slower. We encourage you: pull out a stopwatch and time it: macOS is usually faster, even when your senses tell you otherwise.

When we started the transition from Classic to macOS we made it clear that it was going to be a bumpy ride. Some of you may have failed to note the subtext in that warning: that this upgrade was not always going to be a simple matter of running Update Collection and going back to work. Yes, many users reported no trouble whatsoever and are happily running entierly in macOS today, but for others, some things just didn’t work right.

The key to the happy Helix experience lies in finding the aforementioned “easily implementable workarounds” for things that don’t perform as well in macOS as they did in Classic. There are always at least two ways to do the same thing; usually there are many more. Helix has always been a very forgiving development environment in that it allowed a designer to create without having to be too concerned about whether the route they took to their desired result was the best route to take. Scratching your right ear with your left hand may work, but is it really the most expeditious way to relieve the itch?

In macOS, Helix is not nearly as forgiving. Two cold hard facts have emerged in this process: One is that some constructions that performed adequately before — despite the novel techniques employed — simply do not work at all in macOS. The other is that some perfectly legitimate programming techniques that worked quickly and efficiently in Classic also don’t perform well. Yet if you truly love working in Helix, this can be a blessing in disguise, if you let it lead you to re-evaluate some of those age-old constructions. Looking at the goal instead of the process through fresh eyes, almost always results in a new process that is better than the old. We’ve helped many Helix users work through a wide range of issues and we have a fairly good handle on what works and, more to the point, what doesn’t work; if Helix 6.1.6 doesn’t work for you, don’t give up: call us. We may be able to suggest a few changes that can make a world of difference.

For many Helix users, years, in fact decades, of seeing Helix work a certain way has left little room for tolerance of its new behavioral quirks. We certainly could have tried to make macOS native Helix feel more like Classic Helix, but that was never part of our plan: our plan was to build a Helix that looks and acts like a macOS application. Helix applications that look like Macintosh applications is what Helix users have been clamoring for all these years, and that is what we are striving to deliver. The way we are building Helix today, your code will not suddenly look dated, as it has so many times in the past, should Apple decide to change the look of macOS in some future update.

And as you will learn over the next several months, because we adhered to that plan, we are now in a position of being able to offer bigger and better changes that will enable Helix users to take advantage of more and more of the great capabilities macOS has to offer.

We have long lamented the major detours on the road to macOS: the move from AppleTalk to TCP/IP, the premature death of Classic on Apple hardware and the move from PowerPC to Intel. But that is now, thankfully and for the most part, all behind us.

So what’s next?

For a new product announcement, this one has been a little long. Even by our standards. And we’ve cut a lot! But seven months of nothing demands more than just a little something.

Seven months ago we left you with a tantalizing promise that 2010 was going to be the year of Helix RADE. While the performance work has set back the calendar a bit, we are still hopeful that a usable form of RADE for macOS can be in your hands before 2010 draws to a close.

The results of our RADE Subscription Plan survey will be announced very soon. [Update: The survey results are published and the subscription plan was revealed in a subsequent TLW.] And keep your eyes on the site for news about the Helix 6.1.6 Value Pack. Until then, please head on over to the download page, grab a copy of the Helix 6.1.6 tool of your choice and judge for yourself whether we’ve made a successful transition into the world of macOS.