In This Edition: Helix 6.1.5 is Released About Performance What’s New in 6.1.5? What’s Next?

Crossing back over the line with Helix 6.1.5

30 November 2009 — Weariness has surely overtaken even the most long-suffering of Helix-loving souls. It is even evident in our work. This summer, we made the critical mistake of allowing our zeal for what we were trying to accomplish overtake our core principles to some degree, resulting in a product called Helix 6.1.4 that was, to be charitable, less than extremely-well tested.

When we shipped Helix 6.1.4, we also announced that version 6.1.5 would focus on performance improvements and mark the end of the Preview Release process. However, it quickly became evident that Helix 6.1.4 was one of the most crash-prone releases in modern history.

To be truly fair, significant improvements made their debut in Helix 6.1.4. If you were able to avoid the crashes it was a major leap beyond 6.1.3. It was the first Preview Release that allowed you to do pretty much everything you could do in Classic Helix, even if it was sluggish in places. And because we so desperately wanted everyone to have what they needed, we failed to test it thoroughly and missed some serious issues. And so, once again we have had to delay the performance improvements in order to fix bugs.

In other words: this is not the announcement you were hoping to read today.

When we shipped Helix 6.1.4 in August, we believed that fixing our performance problems was the final obstacle to removing the Preview Release phrase from our splash screens. Yet today’s release — Helix 6.1.5 — still carries that stamp.

While all our problems are far from solved, the primary focus of today’s action is to address the stability problems that plagued 6.1.4. After all, if your program is crashing, performance doesn’t much matter very much.

Past promises notwithstanding, we always reserve the right to do what makes good sense, even at the expense of having to eat a little crow.

When it quickly became apparent that addressing these issues could not be delayed, the performance work was once again delayed so the necessary resources could be devoted to fixing the crashes. With the worst of them at last resolved, what now makes good sense to us is to retire 6.1.4, cross back over that sanity line we so egregiously crossed by putting that product out, and release 6.1.5 without the promised performance improvements, but also without the plague of crashes and other issues found in 6.1.4. Call it another learning experience.

As with version 6.1.4, this update is offered as a free update for those of you who already own Helix 6.1 products, or as an upgrade purchase if you are still back in 6.0 or earlier. And, as before, we are making a separate “for PowerPC” version of 6.1.5 available for those who can not afford to upgrade yet. While the for PowerPC Server, Client and Engine do not benefit from the tremendous speed improvements you get with an Intel-based Mac, they can be installed using your Helix 6.0 keys, so you can benefit from their other improvements without additional expense right away.

A Word About Performance

In spite of our high hopes at the time, a lot of you sat 6.1.4 out. Why? Because shortly after it shipped, word started circulating that Helix 6.1.4 was slower than Helix 6.1.3. We were baffled by this for a while, because our testing showed it to be marginally faster. When this bit of misinformation started to become ‘common knowledge,’ we set out to determine where it was coming from.

Eventually we determined that the problem was this: for many users, Helix 6.1.4 was their first serious attempt at using the macOS Client and Engine. Their reference point was Classic Helix.

Further investigation uncovered that they were running Helix on PowerPC Macs, not on Intel Macs. We’ve always recommended that if your Mac can run Classic (and if you’ve got a PowerPC Mac, it can) then you should run the Classic Helix products. macOS native Helix is required to run on an Intel Mac, but not on PowerPC.

The macOS PowerPC code is, quite frankly, slow with lists. But the Intel code holds up reasonably well when compared to Classic. It’s faster in some areas, slower in others. The table on the right contains some numbers that back that up. One important thing this chart shows is that, where Classic Client took 0.37 seconds to fill in the fairly complex entry view used in our tests, the Intel Client does the same job in only 0.18 seconds — over twice as fast as Classic! (The December 7th edition of The Latest Word contains more performance test results.) While we will make every reasonable effort to keep the Helix performance gap between PowerPC and Intel Macs from widening any further, let us be clear: Intel Macs are the present and the future; PowerPCs are the past.

We have long held that performance is part reality, part “something else.” Perception? Patience? Smoke-and-mirrors? While some things are objectively better than others, in terms of raw speed, there is clearly a perception component to performance.

For example, there is a subtle but noticeable “debug effect” that occurs as each improvement made to Helix, each fixed bug builds and helps to substantiate the impression that things are running more smoothly and thus, if only apparently, faster. The performance differences between the Intel and PowerPC test results in the table are evidence of this effect. Clearly, the more dramatic results are seen on the Intel Macs.

But even though macOS native Helix is faster in some areas, working with lists reinforces the perception that it is “slower than Classic.” We acknowledge that, and have already promised that we are working on solutions, but please do not let a false impression keep you from enjoying the many benefits Helix 6.1.5 has to offer.

What’s better about 6.1.5?

An unfortunate result of the problems with 6.1.4 is that so many of you who really wanted to use the new Power Query continued to be frustrated. One of the best tools Helix has always had at its disposal, both for its primary function as well as its impact on performance perception, is its ability to Query — and especially to “pre-query” — a list. Working with a large list is always faster and easier when query is attached, and the new Power Query provides a much more intuitive, more “macOS” way of paring a large list down to a manageable size. If you work with lists, you owe it to yourself to explore the new Power Query. When searching for a record, don’t just scroll up and down in the list. Rather, open the Query window and let Helix trim the list down to just those records you are looking for. If you can trim your lists down to 2 pages or less you’ll find scrolling is faster than it is in Classic.

The other part of Helix people were eagerly anticipating when 6.1.4 shipped was Document Management. While relatively few Helix users have ever delved into its document management capabilities, those who have will appreciate the great strides that have been made to keep the most useful aspects of this function working in macOS. We’ve known all along that many aspects of document management would be improved simply by being in macOS, and that has largely been borne out in fact. Incorporating OS innovations such as drag and drop editing make it much more efficient. In 6.1.5, you can drag and drop documents directly into document fields in Helix, bypassing the dialogs you once had to navigate. (You can’t drag and drop from Helix to the Finder yet, but we’ll get there.)

Along with other improvements, these two significant forward leaps debuted in Helix 6.1.4. But 6.1.4 crashed. A lot. Not just the Engine and the Client. For the first time in a while, there were even Server crashes. We received reports of crashes during posting operations, of crashes in document management, of crashes caused simply by opening a view! We discovered that virtually any time you put Helix into the background during a lengthy process, it would crash. We addressed these bugs, and just as we were about to ship, somebody noticed that by putting Helix into the background while a list was being processed (for example, Delete All) some of the records were being skipped. And though it felt like there was always “one more bug” cropping up, this clearly was serious, and we knew we had to fix it ASAP. But we have, finally, mercifully, gotten this and all of these other issues under control. The crashes have (mostly) ceased; the results are once again accurate. There are, as always, a few esoteric situations that still cause problems (see the Known Problems page of our Preview Release pages) but we’re back to that spot where 98% of you will be able to use Helix exclusively in macOS.

But (as they say) that’s not all! While one engineer was working on these serious issues, and another was plugging away on RADE, a third took a look at the disparity between the Classic and macOS representation of rectangles on a view. Up until now, we have pretty much been resigned to the fact that some changes in the interface are impossible to reconcile. But we can be perfectionists at times, and when “things don’t look right” it really bugs us. So we took a fresh look at how the rectangles that you placed in your Classic RADE templates were being interpreted in macOS. What we found was a way to add a Classic Compensation Factor to the macOS code, the result being that in many cases, the size and placement of rectangles is now pretty much identical in Classic and macOS. And for those of you who have observed that macOS reduces font sizes sometimes too much, 6.1.5 should make things more pleasant for you as well, as we’ve found ways to ‘fool’ macOS into giving us more room.

We also added a few more flourishes: if you’re one of those who’ve been troubled by the absence of a cold form indicator in macOS, the word “ (Cold)” now appears in the title bar of such windows. Framed checkboxes are framed once again, and some of the little features we had slipped in at the end of the Helix 5.x era — products that were shipped after we had started in earnest on the macOS conversion — have been brought over to macOS. We also noticed that with our crisp new printing code, printing a frame at the full 1 point thickness makes them appear overly heavy, so we added a 70% reduction factor, which results in a more attractive printed page.

A detailed list is found on the What’s New page of our Preview Release pages.

What’s next?

Once, and for a very long time in its young life, Helix was plagued by speed issues. Then, with the PowerPC Mac, and the introduction of Collection Buffers (originally known as RAMJet) in the late 1990s, those speed problems pretty much went away. But then came macOS and a need to find the quickest path to allowing people to use Helix on their new Macs. Now, ironically, one of the decisions that bought us time may have cost us performance. The path Apple gave for bringing our code to macOS works fine on entry views, but exacts a significant performance penalty for lists. (See the table above.) In programming terms: this solution doesn’t scale. But there are alternatives and we are already working on solutions to the problem. We know there is no ‘magic bullet’ so it is going to take a bit more time before more speed comes your way.

How much more time? We don’t know yet. We only know it won’t be here in 2009. Is there an upside to any of this? Well, yes. We know it will happen. We will conquer the speed problem. A popular refrain around here is “We always get our man.” So we need to continue thinking past this issue, continuing to focus on both the performance on one hand, and RADE on the other until the full effort can be focused on RADE and not letting this (large) bump in the road cause us to lose sight of the years and years of positive, productive service we have gotten — and will get — from our Helix applications.

One last word about bugs: Helix 6.1.5 does not fix every bug we intend to address between now and when we ship Helix RADE. Although we really want to turn the page and pour all our efforts in 2010 into RADE, the places where Helix still doesn’t work properly will be dealt with. There will be more updates in the future — particularly the promised performance boost — so if you are seeing problems, don’t despair. Report your bugs and we’ll try to get them fixed as we go along.

We know it’s asking a lot, especially of those for whom 6.1.4 may have been “the last straw.” Please don’t let 6.1.4 spoil your Helix experience. There is so much future ahead of us. Work on RADE continues, and great progress being made. Our traditional end of the year message should bring encouraging information on that front. So please stay tuned…