Tag Archives: Performance

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 6, future proofing

2 Replies

This is the sixth and final post in this series where I explain why this statement holds true:

As a CAD Manager looking after AutoCAD users, or a power user looking after yourself, it’s worth your while to have a copy of BricsCAD handy.

This post explains why adding a copy of BricsCAD to your stable of AutoCAD licenses is a good thing for your future and that of your company.

A CAD Management thing I did a few years ago was to examine the options for replacing AutoCAD and other Autodesk products. I was an AutoCAD loyalist (albeit a somewhat critical one) with over a quarter of a century invested in it. I was looking after the deeply entrenched and very heavily customised CAD environment of a major public utility company that had been using AutoCAD as its primary CAD system since the late 1980s. Hundreds of custom commands were in place and providing priceless productivity benefits. Hundreds of thousands of DWG files were on file, with thousands more coming through every month. The inertia behind AutoCAD was very, very strong. Looking outside the cage was a pretty radical step to take. What led me to that point?

  • Autodesk business policy. Autodesk has become increasingly anti-customer over the years in ways that will be familiar to all readers of this blog. I won’t rehash them here. This leads to…
  • Increasing costs. Autodesk software is expensive and getting more so. Autodesk has made no secret of its intention to move to an all-subscription (rental) model. This is an attempt to treble the ongoing income Autodesk receives, in return for doing as little as possible. Which leads to…
  • Lack of progress. It had become clear that the days of AutoCAD seriously improving from release to release were over, never to return. This isn’t because there is no room for improvement, it’s because Autodesk doesn’t want to improve AutoCAD. AutoCAD won’t be permitted to become too capable because that would just eat into sales of Autodesk’s other products. You’re not going to see 3D parametrics or sheet metal capabilities in AutoCAD: buy Inventor instead. You’re not going to see BIM capability: buy Revit. Beyond the internal competition issue, some years ago, Autodesk leadership lost interest in what it perceived to be an old-fashioned dead-end product. The income from AutoCAD customers is being diverted to fund purchase and/or development of more fashionable and interesting products.
  • Frustration with Autodesk’s Beta program. The goings-on within the Autodesk Beta program must remain private, so what I can say here is limited. I can say that I spent many years contributing large numbers of hours to that program in order to attempt to improve the product. As time went on, the positive results that emerged from that effort decreased; that much is no secret because it is apparent in the product. I felt I was fighting against Autodesk to try to improve the product, and losing. There were a few final incidents that persuaded me to stop bashing my head against that particular wall. I wasn’t the only one. I stuck it out for years longer than many very valuable people who had already given up before me.
  • Proxy server issues. Over the years, Autodesk’s habit of attempting to do sneaky things to access the Internet had caused a variety of problems in a secure proxy server environment. This caused several things not to work, and harmed performance severely in some places. As Autodesk’s developers turned over, things that worked in one release would not work in the next. Attempts to get this addressed as a support issue would result in the environment being blamed. These problems increased over the years as Autodesk threw in more and more connectivity-requiring features. There was a non-zero and ever-increasing possibility that one day, Autodesk would screw things up altogether and leave us with non-functioning software. That has already happened for some people, and although the stoppage has generally been temporary, it is important to have redundancy.
  • Poor performance. AutoCAD has been getting bigger and slower. Downloads are huge and Autodesk does its best to make them as difficult as possible. Installations take an age, as do uninstallations. Startup times are terrible and getting worse. My users were complaining – a lot – and there wasn’t much I could do about it.

That’s what moved me to take a very, very serious look at alternatives. Your motives may differ. Just the desire to have a Plan B in case of disaster might be enough.

If you don’t feel moved to investigate, you may eventually be faced with no option. Sooner or later, the person who holds the purse strings at your company may point to this year’s much bigger Autodesk invoice and ask, “What are we getting for this? How can we reduce our costs?” When that happens, you don’t want to be scrabbling round for answers before that invoice needs to be paid. Look into the options in advance. Are you really wedded to AutoCAD or are you actually tied to DWG?

Days of Future Past

Here’s my suggestion. Examine the available alternatives to AutoCAD and the other Autodesk products you use. Do it sooner rather than later so you get the chance to determine the answers to non-trivial questions like these:

  • Capability. Does the alternative product do everything that AutoCAD does, that your users need it to do? Does it do other stuff that AutoCAD doesn’t that you might find useful? What’s the performance like? How does it work on the hardware you have? Does it have user interface elements that don’t just look good but work productively in practice?
  • Compatibility. You will almost certainly demand extremely good DWG compatibility, but this question goes well beyond that. Will your LISP work? How about DCL? ActiveX support? DOSLib? Other programming languages? Can you carry over your customisation files? Can you make the interface look the same? If you have custom toolbars, or ribbon, or even image menus, do they carry across? Can your users carry across their skills without downtime, extensive training and a productivity hit? Can AutoCAD and the potential replacement coexist without issues? Can you use a common set of custom support files pointed at by both products? Will it work well on your hardware?
  • Add-ons. If you’re using third party products on top of AutoCAD, or if you’re using an AutoCAD-based vertical, is that product or an equivalent available? Does it work well? What do the objects they create look like in plain AutoCAD? Can you round-trip through AutoCAD and back and retain your intelligence? You’re probably going to have to test this with evaluation software and your own data.
  • Licensing options. Is perpetual licensing available? Can you stick on a release for a few years and still purchase upgrades later? Has the company committed to providing you with licensing options or has it made noises about going all-rental? Is network licensing available? Does it coexist problem-free with Autodesk’s network licensing software?
  • Costs. Compare the likely costs for all your options over several years. You’re going to have to make some assumptions. It can be difficult to work out what they should be.
  • Track record. Has the company been around for a while? What reputation does it have? Does it treat its customers with respect? How good is the support?
  • Future prospects. Is the company likely to be around long-term? Is it actively developing the product you’re interested in? Is it innovating? Is it merely following AutoCAD at a distance or charging ahead? Is the product going to be limited by Autodesk-like internal competition?

I went through all of these questions and settled on BricsCAD as the best option in my company’s case. In fact, several aspects made it really the only viable option. The product impressed me with high performance, capabilities well beyond AutoCAD in several important areas, a very high degree of compatibility (particularly LISP but also other customisation files), the availability of perpetual licensing and much lower ongoing costs. The company impressed me with its honesty and attitude toward customers.

Most of all, I was won over because I could see that the product had a future. Subsequent improvements have only strengthened that view.

Obviously, you need to make your own judgement based on your own circumstances. I would suggest looking at all the options, including sticking with AutoCAD permanently, with or without subscription or maintenance. Maybe you can use my investigations as a starting point, but I encourage you to start investigating now rather than when you’re under time pressure and don’t have time to do a thorough job.

It will cost you a few minutes to download and install of an evaluation BricsCAD and start preparing for the possibility of a different future. Maybe it won’t turn out to be part of your company’s future, but it could still be part of your future.

Options are good. Learning is good. Best case scenario, your knowledge is going to save your company money and improve its productivity, and you will end up smelling of roses. Worst case scenario, you’re going to spend some very justifiable time doing something new, different and interesting. I recommend it.

Other posts in the Why every AutoCAD CAD Manager should have a copy of BricsCAD series:

Part 1, fixing drawings
Part 2, 3D operations
Part 3, parts on demand
Part 4, efficiency
Part 5, LISP

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 5, LISP

5 Replies

This is the fifth post in this series where I explain why this statement holds true:

As a CAD Manager looking after AutoCAD users, or a power user looking after yourself, it’s worth your while to have a copy of BricsCAD handy.

This post is about BricsCAD being better than AutoCAD at the one thing that made AutoCAD win the race against its competitors back in the 80s – LISP. That is, AutoLISP (added fully to AutoCAD in Version 2.18) and Visual LISP (fully integrated with AutoCAD 2000).

If you’re a good AutoCAD CAD Manager, you’ll already know the reasons LISP is an extremely important tool, so I won’t cover them here. I may explain those reasons in a later post, but that would distract us from the main point. Why is having a copy of BricsCAD useful to a CAD Manager?

  • BLADE. I’ve covered the BricsCAD LISP Advanced Development Environment in various posts already, and I intend to go into greater detail in future posts. There are enough advantages over VLIDE to warrant an entire series of posts. This is simply the biggest advance for CAD LISP in 20 years; if you’re doing any reasonably complex development in LISP and you’re not BLADE, you’re wasting time and money.
  • Performance. Because BricsCAD’s LISP engine is much more modern than AutoCAD’s, the performance is much greater. In my experience, it’s about three times as fast. Some function calls are as much as 30 times as fast. If you have a user who’s complaining that your routine is taking an age to process in AutoCAD, try it in BricsCAD instead. I once saved a user half an hour in processing time for one polyline by using BricsCAD. Another aspect that will benefit you when programming and testing is BricsCAD’s generally superior performance. Got nothing running and want to get programming in the next 5 seconds? Fire up BricsCAD. Want to do a complex process on a big drawing that makes AutoCAD run out of RAM? Try it in BricsCAD.
  • Licensing. While you’re developing in BricsCAD, you’re not using up an expensive AutoCAD license. You’re using a cheaper (or even free, while you’re evaluating it) BricsCAD license. Also, it’s a perpetual license so if you ever stop paying, you can keep developing as long as you like. Oh, and it’s not going to flake out on you on those days where Autodesk’s subscription licensing server has a meltdown.
  • Extra functionality. BricsCAD’s LISP has the AutoLISP and Visual LISP functions and then some. Some of the DOSLib functions are available without even needing DOSLib, but if you need the full set of DOSLib functions they can be loaded, as per AutoCAD. A range of extended functions are available with the vle- prefix, and the LISP Developer Support Package documents these and provides the source code so you can also use them in AutoCAD.
  • Platform independence. AutoCAD for Mac has severely restricted LISP capabilities, making it unsuitable for use in a professional, efficient custom environment. BricsCAD for Mac and BricsCAD for Linux both provide practically identical functionality to the Windows version. Yes, BricsCAD for Mac really is significantly more AutoCAD-compatible than AutoCAD for Mac.

I do my LISP development in BricsCAD these days, and can attest that it’s well worth the investment in time to get the hang of BLADE.

It will cost you a few minutes to download and install of an evaluation BricsCAD and check out the LISP situation for yourself.

Edit: it’s not just LISP. See James Maeding’s comment below about .NET, too.

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 4, efficiency

2 Replies

This is the fourth post in this series where I explain why this statement holds true:

As a CAD Manager looking after AutoCAD users, or a power user looking after yourself, it’s worth your while to have a copy of BricsCAD handy.

This post is about BricsCAD being more efficient than AutoCAD for some of the things a CAD Manager might need to do. What do I mean?

  • BricsCAD starts up and closes down faster than AutoCAD, much faster in some environments. If your AutoCAD starts up slow (e.g. in some secure proxy server environments), pretty much any job you need to do to a user’s drawing that involves getting in, doing something quick, saving and getting out again is likely to be finished in BricsCAD before AutoCAD is even open.
  • If you perform a more complex operation on behalf of a user that is likely to take a while, there’s a better-than-even chance that BricsCAD will do it quicker than AutoCAD. In some cases it will do it much quicker (e.g. drawing compare).
  • BricsCAD tends to be able to cope with large drawings while using less memory than AutoCAD. If you have a user with a huge drawing who can’t work with it any more in AutoCAD and you need to split, purge or simplify it before it is usable, the very process of doing that in AutoCAD can itself be unworkably slow. Try the same thing in BricsCAD and there’s a good chance you’ll get the job done in a fraction of the time and without the same level of frustration.
  • If you perform a batch process that operaties on a set of drawings, under most circumstances it will be finished in BricsCAD well before the same thing is done in AutoCAD. Maybe this means you can process a set of drawings over lunch rather than wasting all afternoon on them or waiting until home time before setting the batch going. Plus you’re occupying a cheap BricsCAD license rather than an expensive AutoCAD one. Also, because BricsCAD uses much less RAM than AutoCAD while running, you can run your batch processes on that old PC sitting in the corner rather than having your top user sitting around watching your top spec PC grind away.
  • Certain user interface structures in BricsCAD are much more logically arranged and efficient to use than the AutoCAD equivalents. For example, if you have a drawing with an obscure setting that needs changing, unless you have an impeccable memory, you’ll find that setting much more quickly using the BricsCAD Settings command.

As I mentioned in my last post, this series is all based on stuff I’ve done in real life as a CAD Manager for a primarily AutoCAD-using company. Feel free to add your comments with your own experiences, even if they differ from mine.

It will cost you a few minutes to download and install of an evaluation BricsCAD and check out the performance and efficiency for yourself.

BricsCAD’s LISP kicks sand in the face of AutoCAD’s

10 Replies

If you’re a power user or CAD Manager transitioning from AutoCAD to BricsCAD, one of the things you’ll like is that almost all of your LISP routines will just work. That’s not an statement that can be made about various Autodesk products that bear the AutoCAD name, such as AutoCAD 360, AutoCAD LT and AutoCAD for Mac.

It’s not just simple old AutoLISP code that runs in BricsCAD, but complex dialog routines that use DCL, and Visual LISP stuff that uses ActiveX. Yes, even on the Mac and Linux platforms. Some DOSLib functions are built in and the rest can be loaded, as with AutoCAD. Even OpenDCL is supported. It’s a quite astonishingly high level of compatibility.

But it’s not 100%. There are minor incompatibilities, system variable and command-line differences that cause problems in a handful of cases. It’s often possible to work around these and still retain the same code that works in both AutoCAD and BricsCAD. Reporting LISP bugs and incompatibilities to Bricsys generally gets them fixed super-quick.

Also super-quick is the speed at which your code will run. It’s immediately noticeable when running any LISP code that needs to do a bit of processing that it just gets done faster in BricsCAD than AutoCAD. Fast enough to extract the following comment from one of my AutoCAD users trying out a linework cleanup routine in BricsCAD:

Wow.

 
User impressions are one thing, but how about measurements? Today, I had a support job to do that involved running one of my LISP routines. I ran it on both AutoCAD 2017 and BricsCAD V17 on the same PC. AutoCAD took 2970 seconds (about 49 minutes), BricsCAD 1030 seconds (about 17 minutes). Over half an hour saved on one operation. That’s 2.88 times faster, which is consistent with my previous observations with a variety of routines.

Upshot: if you’re doing work where there’s a lot of LISP processing going on, switching to BricsCAD is going to save you a shedload of time.

There is a downside to BricsCAD’s LISP, and it’s a big one; no VLIDE. No equivalent, either. There are various programming editors around that can help with editing code, but no substitute for integrated debugging. It means if you’re a power user, CAD Manager, developer or support person, you’re probably going to have to keep one working copy of AutoCAD around even after you’ve completed the transition to BricsCAD.

Because VLIDE has been in maintenance mode for over 15 years it remains virtually unchanged year after year (including ancient bugs). So it doesn’t matter that much which AutoCAD release you have hanging around. Assuming you’re a perpetual license holder, when you drop the maintenance contract on one of your AutoCAD licenses, you’re entitled to keep using the software as long as you wish, albeit only the current release at the time the contract ends. How long the software will keep working is another matter, depending as it does on factors not entirely within your control.

This is an imperfect solution. Even keeping a copy of AutoCAD around won’t help much if you’re debugging a problem caused by something specific to BricsCAD. Filling the VLIDE hole is something Bricsys needs to work on.

Cloud benefits – processing power

Leave a reply

A frequently stated advantage of CAD on the Cloud is the access to large amounts of processing power. Instead of relying on your lowly local processor to perform complex tasks, you can instead zap the job up to the Cloud where vast numbers of processors churn away in massively parallel fashion and then zap the results back to you before you’ve even had time to head for the coffee machine.

This is a scenario that applies only for certain types of very complex tasks that are suited to subdividing the calculations among many processors. Autodesk already has a big toe in the waters in several of those areas. The recent Autodesk Cloud changes made available Inventor Optimization, Cloud Rendering, Green Building Studio and Conceptual Energy Analysis to a small subset of Subscription customers. It’s safe to assume that these services will be improved and expanded over the next few years. (Is there anybody out there using Autodesk Cloud services for these processor-intensive tasks? Let’s hear about your real-world experiences.)

What this doesn’t mean is that it makes sense for us all to be using CAD on the Cloud, all the time. The processing time gained by using the Cloud is offset by the communication time spent passing the data back and forth, so any processing gain has to be substantial to make it worthwhile. Twenty years ago, when every zoom extents was followed by a looooong wait, a big swag of extra processing power would have come in very handy. These days, processors are ridiculously fast in comparison. They are also very cheap and getting cheaper. Even low-end PCs have had multiple cores for some years, and these days seeing eight almost unused cores on your performance monitor is pretty normal.

The performance of today’s CPUs and the variable performance of today’s Internet, mean that calculations need to be very substantial to make them worth outsourcing to the Cloud. For the vast majority of tasks associated with using CAD software you simply don’t need to hand the job to somebody else’s hardware, because there is ample capacity right there on your desk.

(As an aside, whether it’s on your desk or a server farm, writing software that takes advantage of all those cores must be really difficult. I say that because today’s CAD software seldom uses more than one or two at the same time. Even a seemingly straightforward split like loading AutoCAD’s Ribbon while allowing you to start drawing appears to be too hard. It took Autodesk four Ribboned AutoCAD releases to even attempt this, and the result is a failure; the cursor lag while background loading the Ribbon is unacceptable.)

For tasks where there is the technical potential to share the load, a remote service still might not be the best solution. How about a private cloud instead, where the processing load gets shared between your company’s idle processors via your LAN, and your data never leaves the premises? It seems to me that such a solution could provide most of the Cloud benefits and remove almost all of the concerns. This has already happened in pilot with some Autodesk software. I’d like to see more emphasis placed on private-cloud-friendly software, because I think it has a much better chance of customer acceptance and the development effort is less likely to be wasted.

Studying Autodesk’s productivity study

8 Replies

Heidi Hewett just reported the following on her blog, about a productivity study:

According to a recent independent study, AutoCAD® 2011 can help you work up to 44% faster with the latest productivity enhancements.

I have a couple of problems with that sentence. First, it’s not an independent study. It’s a study conducted by long-time respected CAD figure David Cohn, but it was specified and paid for by Autodesk:

This productivity study was performed at the request of Autodesk Inc., which funded this work.

That’s not exactly independent then, is it? Second, the study does not state that AutoCAD 2011 is responsible for a 44% improvement. That’s a figure that combines both the effects of AutoCAD 2011 (over AutoCAD 2008), plus the effects of using a newer, faster PC. Just stating that figure wthout such a disclaimer is misleading.

Now to the study itself. Let me make it clear that I have no problem with David Cohn, who is respected, experienced and honest. I do not doubt that his study accurately describes his observations of the time taken to perform the chosen operations on the chosen drawings. The problem is that the study is designed to concentrate purely on a set of AutoCAD operations that benefit from the changes of the last three releases. In other words, the dice are very heavily loaded. To David’s credit, he states that very clearly in the study report:

Each drawing was chosen based on a number of criteria designed to showcase one or more features of the software that did not exist in AutoCAD 2008 but were added in subsequent releases. While each drawing could certainly be produced using the features and functions available in AutoCAD 2008, the advanced capabilities added in subsequent releases would likely enable a typical user to produce the drawing faster using AutoCAD 2011.

Since the premise of the test was to determine how much time could be saved by using a new feature, the test itself was already predisposed to show that using AutoCAD 2011 is more productive than using AutoCAD 2008.

A quick skim-read shows that there are several other problems with the study. For example, it doesn’t attempt to measure the productivity of those operations that are common to both releases, which are much more likely to be used in bulk by typical users. The report states that the Ribbon interface is likely to be more productive, but makes no attempt to justify that by comparing the exact same operations performed using the two interfaces.

In addition, both AutoCAD 2008 and 2011 are measured on a typical middle-age PC using XP, but only 2011 is measured on a modern PC running Windows 7. The report states that the latter tests were performed after the former tests, so the times will also be biased by familiarity with AutoCAD 2011, the drawings and the operations required. That’s where the 44% figure comes from, and it doesn’t mean anything.

What’s the point of studies like this, that are self-evidently designed to produce a good-looking outcome? Who are they supposed to fool?  Come on Autodesk, either do these things properly or don’t do them at all. Please.

AutoCAD 2011’s new Help system – what do you think?

15 Replies

With all this talk of clouds in the air, it is interesting to note that Autodesk has moved AutoCAD’s Help system to a browser-based format, with online access as the default. So, how has Autodesk done with this first dipping of its toes into the cloudy waters with its primary mainstream product? I’ve already had a couple of unsolicited comments on the subject, and I’d like to hear from you. How do you rate the following, compared with previous releases?

  • Performance (online)
  • Performance (offline)
  • Search results
  • Content completeness and accuracy
  • Ease of manual browsing
  • Efficiency of user interface
  • Concept of online Help
  • Anything else you want to mention

Please comment to express your views and use the poll on the right to provide an overall rating of the new system.

Does your AutoCAD get its wrods worng?

6 Replies

A problem I’ve seen affecting keyboard users (particularly fast ones) in recent AutoCADs (since 2006) is that the characters entered into the command line are not always the ones you typed. Or rather, they are the ones you typed, just not in the right order. In particular, I’ve seen the first couple of characters get messed up, so you might get ILNE instead of LINE. In addition to the annoyance factor, this is something of a productivity killer.

Has this happened to you? If so, please comment. Any comment is welcome, but it would be great if you could provide the following information:

  1. AutoCAD (or vertical) release(s) where you have seen this happen. Also mention any recent releases where you have seen it not happen.
  2. Command line status when you have seen this happen (docked, floating, off, all of the above).
  3. Dynamic input status when you have seen this happen (on, off, on but with some options turned off, all of the above).
  4. Screen configuration when you have seen this happen (single, dual, either).
  5. AutoCAD main window status when you have seen this happen (maximised, floating, either).
  6. Other than this problem, does AutoCAD’s general response to input seem “sticky”? Sticky keyboard, mouse, or both?
  7. Other than AutoCAD, do any other apps give sticky response on the same PC?
  8. General PC stats (OS, CPU type and speed, RAM size, graphics card).

Please add anything else that you think might be useful in tracking this down or working around it. If I learn anything that might be useful, I’ll report back in a later post.

Autodesk answers – 4 of 4

8 Replies

The final question is from metis:

Q: why is program size increasing and performance dramatically decreasing as hardware specs dramatically increase? as features “improve” and are added functionality should not be removed, and code should be streamlined.

seriously aren’t there any real programmers out there anymore? this thing isn’t written in java by a bunch of scriptkiddies (although 2009 sure is skinned like it was).

A: We made a number of performance improvements in AutoCAD 2010 over the previous release, and would appreciate hearing from you if you are encountering significant performance slowdowns with this latest release. If so, please send us details on what you were doing at the time, sample files if possible, and details on the machine you are using. This will help us improve performance further in upcoming releases of AutoCAD.

AutoCAD performance and productivity

8 Replies

I have closed the performance and productivity polls as described in my posts here and here, and the results can be seen in the Polls Archive. As with most of the other polls I’ve run here, the distribution of votes has not changed greatly after the first few days.

It is clear from the very different voting patterns in the two polls that blog nauseam readers are smart enough understand the difference between the two questions. The performance poll has a very clear skew to the “slower” side. This supports the empirical evidence I’ve seen elsewhere that people perceive AutoCAD as getting slower. This is stuff they’ve noticed for themselves, not a few milliseconds here and there.

On the other hand, the productivity poll results show a much more even distribution. The five options are pretty equally represented, except that “a lot more productive” has suffered at the hands of the most popular choice, “a bit more productive”. If you calculate the mean result, it is almost bang in the middle. It’s actually slightly worse than that, but by such a very small margin that it is not statistically significant.

Overall, we can say that the average viewpoint expressed here is that people clearly see AutoCAD as getting slower, but that its productivity has stayed about the same. So, does this let Autodesk off the performance hook? If a slowing AutoCAD is balanced by productivity-enhancing features, does performance matter? In my opinion, the answers to those questions are no and yes respectively.

It’s not a safe assumption that productivity features are balancing speed issues for everybody across the board. A new feature may help some users’ productivity, maybe even a majority of users, but it won’t help everybody. Some new features even harm some people’s productivity, which is one more reason for being grateful that Autodesk generally lets us turn them off (although it has been forgetful about that in some cases in recent years). Performance is one of the many things that impact productivity, but unlike most new features, is something that impacts the productivity of everybody. Even a first-time user has to sit around waiting for AutoCAD to start up, while a fast power user will be rendered less productive, and certainly more frustrated, by relatively small hesitations.

Furthermore, if AutoCAD is about as productive as it was a few releases back, is that good enough? Or should Autodesk be providing noticeably more productivity in return for our Subscription or upgrade payments? If not, why do we continue to hand over our hard-earned dollars? Why do we go through the upgrade process at all, with all its attendant costs, struggles and inconveniences?

Autodesk, please put much more effort into halting and reversing AutoCAD’s performance slide. It doesn’t have to be a competition between performance and productivity. Improve the former and the latter will also improve.

Is AutoCAD becoming more or less productive?

Leave a reply

It seems that most of you are convinced that AutoCAD is getting slower, but I’ll leave the poll going for a while longer. But even if AutoCAD is getting slower, does that mean that it’s actually less productive? Do the new features introduced in recent releases allow you to produce more useful work in a given time, despite making you wait from time to time? I’ve added a new poll to see what you think.

In which direction is AutoCAD’s performance going?

6 Replies

I see quite a few comments in various places that say that AutoCAD’s performance has been getting progressively worse by the year. Is this what most people think, or just the viewpoint of a few complainers? Let’s find out, shall we? I’ve added a poll that asks for your opinions. Feel free to comment, too.

Note that this is a poll about raw performance, not productivity. It’s possible (though difficult) to make a program go slower but still allow you to produce more work in a given time, so I’ll cover the productivity angle in a later poll.

This poll is purely about how fast AutoCAD seems to you. How often do you find yourself hesitating, or waiting, or even going for a coffee break, while AutoCAD does its stuff? Is this getting better or worse? If you compare it with an earlier release, does it seem faster or slower? It is to be expected that some things will get faster and some slower, but what’s your overall impression?

AutoCAD 2009 – Layer Palette and performance

5 Replies

If you’ve noticed some normal drafting operations are much slower in AutoCAD 2009 than in earlier releases, try turning off the new Layer Palette and see if the problem goes away. For example, editing viewports with the Layer Palette visible can be completely unworkable. Don’t just auto-hide it, close it altogether.

Another problem presented by the Layer Palette is that any layer changes you make are applied as you make them. This sounds great in theory, but if each operation takes a while to perform then that’s much less efficient than the old method where all changes are made at once when OK or Apply is picked.

I know a non-modal layer interface was a common wish and it sounded like a cool idea, but now Autodesk has actually been kind enough to grant this wish I’m finding I prefer the old method. I generally don’t need access to all that layer functionality all of the time, so it makes sense to only have the interface occupying that big slab of screen real estate when I actually need it. Your requirements may differ, of course.

If you’re a layer Luddite like me, you can use the old interface by issuing the Classiclayer command. Alternatively, if you set the undocumented system variable LAYERDLGMODE to 0, the Layer command will invoke the old interface instead of the new one.

AutoCAD 2009 – The Prequel Part 19 – Menu Browser

7 Replies

You have undoubtedly noticed the large red A in the top right corner of the AutoCAD window. Personally, I don’t like the look of it. The concept is rather Fisher-Price and the execution is poor. No competent graphic designer would align the top of the red A exactly with the top of its surrounding button area like this:

The Big Red A

There are so many examples of poor graphic design in AutoCAD 2009 that the overall visual effect is close to that of a rather amateurish shareware product. That’s not what you might expect of a multi-billion dollar company that can undoubtedly afford to pay talented people to do much better, but it’s a relatively trivial matter. You probably want to know how it works, rather than what it looks like.

What’s living under that big red A? It’s called the Menu Browser, and it’s a mixed bag. There’s some useful new stuff under there, which I’ll cover later. In this post I’ll just describe using it to browse menus. Frankly, it’s not very good at that. The video below shows you why, and here are some notes to go with it.

  • On a fast machine, the reaction times are slightly sticky. Users of slower machines will experience some frustration; I have waited over three seconds for a reaction. Just like the Ribbon, it’s the initial click that hurts the most, with subsequent clicks on the red A being rather quicker.
  • Because the menu structure is one level deeper than traditional pull-down menus, you need a minimum of one extra click to do anything.
  • Because the Menu Browser is artificially limited to a small section of the screen (no, you can’t resize it), the menus don’t all fit. That means you not only need to perform extra actions to select certain commands, you need to perform extra actions to even see them. That is, if you’re browsing the menus, this new interface is markedly inferior to the old one.
  • With pull-down menus, you need a click to start with, then you can hover (or optionally click) to burrow down until you get to the command you’re after. In the Menu Browser, you need a click, then a hover (or optional click), then it’s all clicks from then on. That is, it’s close to the exact opposite of what you might expect, it’s not even self-consistent, and there is more clicking required than before.

Menu Browser - not so good for browsing menus

If you regularly use pull-down menus, you may as well type MENUBAR 1 as soon as you install your new AutoCAD. You will lose a strip of screen real estate, but you will have your old menus back.

If it’s an unhappy experience using the Menu Browser to browse menus, what else can you use it for? Among other things, you can use it to search menus. More on that later.

AutoCAD 2009 – The Prequel Part 17 – Ribbon Performance 2

Leave a reply

Testing performance under Vista can be an interesting experience. The trouble is, Vista tries to improve its performance by observing what you do and caching it for later use in case you do it again. This leads to something akin to the observer effect in science, where the very act of observing something has an effect on what it is you are observing.

Every time I test Ribbon tab switching performance in Vista, the results improve. In XP, the worst tab switching time I saw on my Core2 PC was 1.6 seconds for the first exposure of the Tools tab. In Vista, the same thing took 1.2 seconds the first time I tried it, but subsequent attempts (after closing and restarting AutoCAD but not rebooting) gave results in the 0.5 to 0.6 second range.

I tried turning off Vista’s pretty Aero interface and saw improvements of about 0.1 seconds in every measurement. With Aero off and testing a second time, I saw first tab switches from 0.2 to 0.6 seconds and second tab switches between 0.3 and 0.5 seconds. Most switches were around the 0.3 second mark.

While I hesitate to base any firm conclusions on such shaky ground as these rather unscientific tests, I can say this with some confidence: it is possible to have a system running AutoCAD 2009 under Vista where the Ribbon tab switching performance meets in most cases, and is close to meeting in all cases, the 0.3 second mark that most users perceive as instant response. However, your mileage may vary. Correction: your mileage will vary.

AutoCAD 2009 – The Prequel Part 16 – Ribbon Performance 1

Leave a reply

One of the things I like least about AutoCAD 2009 (at least in Release Candidate form) is that I find it very “sticky”. That is, I find myself having to wait for an instant here, then again there, yet again over there. Most of my testing has been on a middle-aged Pentium 4 (3.0 GHz dual core – not too ancient), and it is particularly noticeable there. On my newer Core2 machine, things are better.

When AutoCAD 2009 starts shipping, I suspect your perception of it will be strongly influenced by your hardware. Top gun users on slow machines are going to feel frustrated; slower users on fast machines will wonder what the problem is.

I made a video that shows Ribbon tab switching performance. This is an important aspect of the new interface. Because the Ribbon hides tools behind different tabs, quick access to those tools relies on near-instant tab switching. How well does AutoCAD 2009 do at that? Let’s have a look on a fairly quick PC (Core2Duo E6600 with 4 GB RAM, under Windows XP SP2 32 bit). I intend to do the same in Vista later.

Ribbon tab switching performance in XP

Measured on a faster machine and viewed objectively, it looks rather better than my perceptions from the slower machine had led me to believe. The real problem is the first exposure of each tab, because after that the tab contents can be retrieved from cached memory. The Tools tab is tardiest; 1.6 seconds here translates to 3 seconds or more on an older PC. For the most part, the tab switching speed is acceptable after the tab has been exposed for the first time. For most users, a delay of 0.3 seconds between input and response is quick enough to be considered instant, and most tabs switch in a time fairly close to that after the first exposure.

One way of avoiding or reducing tab switching frustration is to make your own custom Ribbon with a home tab full of the things you use most of the time. How easy is that? Unfortunately, it’s not. Using CUI to make Ribbon parts is not a pleasant experience. That interface makes the Ribbon look super-snappy in comparison. The Ribbon’s more complex internal structure combines with CUI’s snail-like performance, bugs, restrictions and design errors both old and new, to make custom Ribbon creation a loathsome task.

AutoCAD 2009 – The Prequel Part 13 – ViewCube

1 Reply

For many 3D users of AutoCAD, the ViewCube is likely to be the most useful new thing in AutoCAD 2009. There are a couple of problems with it, at least in the Release Candidate:

  1. It does not work in 2D wireframe mode (which is, paradoxically, where 90% of my 3D work is done). You need to choose another visual style before it will appear.
  2. It seems to slow things down quite a lot in complex drawings.

That said, if you have more than enough computing power for the drawings you usually deal with, then this is a very, very nice interface addition. You can just pick intuitively on the various parts of the ViewCube and your view of the model changes accordingly. You can also click and drag on the cube, and it will move where you place it, while snapping on to the various 45 and 90 degree view directions when you get near them, in the same way that Polar snap works. There is a right-click menu with a bunch of useful options, including a quick and easy switch between parallel and perspective views.

Messing with the ViewCube

You can also easily switch between User Coordinate Systems using the little menu thing under the cube. Unlike some of AutoCAD 2009’s new user interface elements, the ViewCube looks like a finished, polished tool and provides a genuine boost to productivity. Beautiful.

AutoCAD 2009 – The Prequel Part 10 – Dude, where’s my Dashboard?

Dude, Dashboard’s dead. Defunct. Done. AutoCAD 2009 replaced the Dashboard with the Ribbon. If you type in the DASHBOARD or DASHBOARDCLOSE commands, they are just converted to the RIBBON and RIBBONCLOSE commands, which turn the Ribbon on and off.

If you’re a fan of the Dashboard (and I never was), there is good and bad news. The good news is that you can right-click on various parts of the Ribbon, pick Undock and you get a Dashboard-like floating vertical Ribbon that can be resized and configured very easily in terms of turning panels on and off. You can’t do that with Microsoft’s Office 2007 Ribbon. Performance aside (more on that later), I generally prefer the way the vertical Ribbon works, compared with the Dashboard. But I’m still not a fan.

AutoCAD 2009's Vertical Ribbon

The bad news is that if you put a lot of effort into customising your Dashboard in 2008, your work is lost. There is currently no automated migration path from your Dashboard to the Ribbon, so it’s time to start again. This involves using CUI, and unfortunately the process is slow and immensely frustrating. This is due to a combination of the long-standing CUI shortcomings and a set of new ones introduced to go with the Ribbon. Buy yourself one of those squeezy stress-ball things, you’re going to need it.

AutoCAD 2009 – The Prequel Part 8 – Vista Startup Times

9 Replies

I’ve now tested startup times of various AutoCAD releases under Vista. Here are the results, alongside the XP results for ease of comparison:

Release First
Startup		 Subsequent
Startup
XP Vista XP Vista
12 8.6 – 8.2 –
13 2.6 1.8 1.3 0.8
14 2.1 – 0.5 –
2002 3.2 2.1 0.6 1.1
2004 – 4.3 – 1.7
2005 – 7.9 – 4.5
2006 14.9 8.7 2.6 4.4
2007 13.8 11.9 3.5 6.6
2008 14.6 10.5 3.6 6.0
2009 28.9 17.3 7.2 13.3

Same caveats as before, plus the following:

  1. Some AutoCAD releases were not installed on both XP and Vista partitions, hence the gaps in the table.
  2. The Vista tests were performed on the same PC as the XP tests.
  3. The system had a 1 GB USB key hanging out the back, giving Vista a theoretical startup benefit over XP.
  4. It’s very difficult to get meaningful performance results out of Vista because its SmartFetch and ReadyBoost technologies are doing their best to improve performance without user intervention. I may be a geek, but I’m not a good enough geek to be able to tell what Vista was doing behind my back during these tests.
  5. Repeated startups of AutoCAD 2009 revealed a gradual improvement in startup performance. Startup times went 17.3, 13.3, 12.5, 12.5, 11.0 seconds.

Make of that what you will. In short, in my tests AutoCAD 2009 startup time in Vista is still roughly double that of its recent predecessors and about ten times longer than older releases like R13 and 2002.