Axure 8, MacOS : Slow like watching paint dry... like Axure 7


#1

Hi guys,

LET ME BE CLEAR:
On one hand: You guys do an awesome job with Axure. I wouldn’t have my job without Axure.
On the other hand: I want to throttle Axure every other day, every 15 minutes.

It’s slow. It was slow in 7. It was slow in 8 beta. It’s slow in 8. Even slower in 8.-3303, if that is possible.

I’m on a Mac. I’ve re-installed Axure again and again.
Is this is a Windows app ported onto Mac, instead of being written a Mac-native app?
It feels like the old Microsoft Office apps written for windows, but straight ported over to Mac.

I monitor Axure’s memory usage in Mac OS’s Activity Monitor, and it’s normal to see it go form 900mb to 2gb. Yes, even in Axure 8.

Where is Axure slow? Let me count the ways, and times when it displays the Mac OS spinning beachball, and Activity Monitor says “Axure RP 8 (Not responding)”:

  • When switching from one tabbed-window to another
  • When previewing (Command+Shift+P)
  • When opening a dynamic panel
  • When closing a tabbed-window
  • When opening the Widget Styles Manager window/palette

A one second wait would be tolerable, but we’re talking 20 to 40 seconds. It kills any momentum I have.

(I won’t start on the 7-to-8 conversion artifacts, or the pre-.3303-to-.3303 text formatting changes.)

I’m all day on a 28 mb Axure file, when it should be a half-day effort.

This is on a MacBook Pro (Retina, 15-inch, Mid 2014) with 16 GB of RAM, 2.2 GHz Intel Core i7.

Any help would be appreciated please.

Thanks,
John


#2

Hi John,

Haha, love the handle. We are looking seriously at optimizations for Axure and hopefully some Mac specific ones. It is really hard to determine exactly what might be causing slow down without being able to check out some specific cases. To that end is it possible to send in your file? It could be a great sample for potential speed up now and larger changes for a future 8.1 (or similar) release. You can send it to support@axure.com if you don’t like sharing it on the forum.

I’d also like to have you try the newest release candidate, too. These are inherently more dangerous, but this one has been out for a while and we are just going to release a small update with a few more fixes and then push it to the full live branch, so you can feel pretty safe with this one.

Release Candidate | Axure

I don’t think this will have drastic improvements for you across the board, but I think 3 of your line items could revolve around a some fixes to panel state switching that will be improved in this RC and the next time we push the dev branch to RC.

I’d like to get to bottom of your slowness, hopefully we can get your file to a workable state. Thanks!


#3


Hi Ian,

Appreciate you working with my frustration-humor, as this slowness has caused me to miss 2 deadlines now.

Sending you the file, as sensible as it would be, would get me canned, unfortunately.
So, short of that, let me ask you about practical tips and guidelines:

As there are many ways to build any given prototype, are there certain ways that are most economical in terms of not straining Axure?
Is there a ranking order for the below in terms of least impact on Axure app performance?

  • In terms of least-memory/processor-usage, when should I break up one prototype PAGE into several PAGES?
  • In terms of least-memory/processor-usage, when should I break one prototype FILE into multiple FILES?
  • How much do GROUPING and NESTED GROUPING of widgets slow down Axure?
  • How much do DYNAMIC PANELS, and NESTED DYNAMIC PANELS slow down Axure?
  • Does using MASTERS, instead of the same widget/graphic multiple times, save on processor/memory?
  • What interactions are the biggest processor/memory hogs?

Thanks!
-John

BTW, if your keeping lists: A great Mac-specific improvement would be for Axure to NOT ask if I want to save a file, if I’ve only opened it and looked at it, not having made any edits.


#4

Hi John,

Of course! That is no good to hear. :confused:

– In terms of least-memory/processor-usage, when should I break up one prototype PAGE into several PAGES?

The largest factor is usually Widgets per page. The more you are willing or able to break up pages the faster it should be. I believe our product support generally recommends about 500 Widgets per page, but we try to optimize for many more than this. However, this includes Widgets in Dynamic Panels, Masters and Groups. Also, any Widgets unplaced on different Adaptive Views, if you are using them, can have an impact.

– In terms of least-memory/processor-usage, when should I break one prototype FILE into multiple FILES?

Generally overall file size doesn’t play as large of a role in general use performance. If the file does get very large saving, loading, and first opening of the file can start to suffer in performance. How large are you dealing with? It generally shouldn’t have a huge impact (besides saving and loading) until you are getting to the 100MB+ range. You could try turning off auto-save backups to see if that helps. ‘File -> Backup Settings…’

– How much do GROUPING and NESTED GROUPING of widgets slow down Axure?

Groups and heavy nesting were definitely an issue in some earlier releases and betas of 8. If you keep on the latest releases though, they should have minimal impact unless the usage is an extreme case. Generally a couple hundred groups, nested 3 or 4 down even, should be manageable from a performance standpoint.

– How much do DYNAMIC PANELS, and NESTED DYNAMIC PANELS slow down Axure?

Dynamic Panels and nesting generally won’t matter too much, except in the fact that you can quickly up the Widget count referred to above. If you have 500 Dynamic Panels all with empty states, it won’t be too bad. However, more likely a giant state can get duplicated and that will quickly bloat the Widget count.

– Does using MASTERS, instead of the same widget/graphic multiple times, save on processor/memory?

Masters could help and are good to use anyway for future editing of the project, however besides some edge cases, I believe things should be cached at a lower level and heavy usage of Masters won’t have significant impact over the other items discussed.

– What interactions are the biggest processor/memory hogs?

By interactions are you referring to our Interactions in the Properties Pane? These shouldn’t matter too much, but using large Repeaters which are heavy in Interactions can cause so pretty significant slow down.

General tool interaction, the heaviest hitters are going to be switching pages, loading and saving. Generating and previewing prototypes (which can also cause loading and saving) will also hit it pretty hard. But normally none of these should have an issue unless dealing with huge pages. Do you have a feeling for how large your pages are getting or think you have a sample you could send in?

– A great Mac-specific improvement would be for Axure to NOT ask if I want to save a file, if I’ve only opened it and looked at it, not having made any edits.

It definitely shouldn’t be asking you to save every time. It will do this if you are working on an unconverted earlier version of a page. Once you open and save it in your current version it should no longer ask you this. This is on a per page basis, though. Are you working with a normal project or a team project?

We are still working on optimizations and hopefully will be rolling out a few in the coming weeks and months. I’ll let you know as those go live and if it doesn’t seem to be helping maybe we could set up a screen share or similar to help try to get to the bottom of things.


Which is quicker? [[ Window.width ]] or [[ 1024 ]]?
Unpublished pages and slow performance
Problems with Preview
Axure Lagging Issues
Save is slow: Improve saving strategy
#5

Hi Ian,

A long overdue thanks for helping me out on this.
It was a crazy few weeks. I’m going to post your reply on our company UX intranet in case it’s of use to other Axure-users here.

For what it’s worth, copying my renegade Axure file over to a server, and then copying it back over to my Mac, cleared up a good amount of the slowness.

Many thanks again for the prompt assistance!
-John


#6

That’s great to hear! We are still working on optimization and I am hoping at least one or two will have significant, positive impact for you, still. Keep checking for updates and I’ll post again when most of them are live.

Thanks!
Ian


#7

Thanks for the tips Ian. We are having similar slow performance issues on group projects that’s causing significant issues. We look forward to an update on Macs.


#8

You guys at Axure have got to address - as a matter of URGENCY - the software’s speed. Over the course of a couple of versions Axure has turned from a fast, responsive joy to use into a bloated, slow, frustrating battle to get pretty much anything done. Among many many issues are:

1/ time take to generate a preview. TOTALLY unacceptable for it to take 20-30 seconds or more - if I’m in a sprint review or a demo it’s just EMBARRASSING!

2/ When I export to Axshare, sometimes the responsive mobile view loads when I do alt-cmd-m (Firefox), sometimes it doesn’t. Totally unacceptable wheh those prorotypes are being used for user testing.

I can’t send you my prototype file - it’s a sacking offence at my company to share asset outside the organisation - but I’m not doing anything I haven’t done a thousand times before in previous versions: and indeed as I’ve got better at Axure (smarter use of dynamic panels, increased use of masters etc) the prototypes are MORE efficient so should load FASTER.

For the first time since starting to use Axure in 2009 I am seriously wondering whether there’s another product out there that would let me do what I need to do quicker and with less pain - without the interminable waits to generate previews, without the CONSTANT ‘thinking about it’ spinner coming up. Axure has gone from being a joy to use to being a f**king pain in the ass. Fix it, and soon, or I’m gone.


#9

Hi Ian,

Yes. We’ve found some sizable opportunities when working with complex pages on the Mac and several updates are in progress.

We’ve also been looking for slow spots while previewing and generating HTML. Some of the browser-side optimizations have been released and there are a couple opportunities on the generation side. We usually don’t see 20-30 seconds unless there is something going on with repeaters or the page is very large.

I’d really like to fix whatever it is that is making your preview take that long. I know you can’t share your file. Can you do a web meeting or is there any way to strip and send just one page of the prototype that takes that long to preview?

Same for the adaptive issue. If that is one of the slow pages, I’m wondering if the browser is timing out. We don’t have other cases of this reported so it’s difficult to know where to start without seeing it.

I’ll send an email to you as well to follow up.


#10

I have been experiencing a very slow process of opening new pages in the same window. My project is not big at all is about 6-7 pages, When I click on a link to take me to another page it would take 5-10 sec to open the new page in the same window.
I’m using Axure 8 v. 8.1.0.3366

Any ideas what could it be wrong?


#11

Hi isra26,

Ah, the biggest impact on performance isn’t the overall file size or the amount of pages the file contains, but the size of each page, i.e. the amount of widgets that are on a single page. The performance and loading time of a file that is 10MB in size will be a lot faster if the 10MB is spread out over multiple pages, for example, compared to a file that is 10MB in size that has 9MB concentrated on a single page and 1MB on another. When clicking on the link to take you to another page, for example, how big is that other page? Are there a lot of widgets, repeaters, and dynamic panels on it?

That said, if the pages in your file are unusually slow to load, please upload the .rp file here, and I’ll be happy to take a closer look to see if there’s something else that may be contributing to the lag. If you’d rather keep the file private, you can email that to support@axure.com. Ty!


#12

Ian,

Sorry, but those suggestions are really fluffy distractors. Axure has seriously serious latency problems. Two years on and this issue has still not been addressed.

I have a single page project with one repeater. Loading times on conditionals are in seconds. Not 1, not 2, but more. As John says, it’s like watching paint dry.

Axuew really should address this problem soon because I (we?) will be moving to the competition - when I (we) decide which competitor to move to - soon.

I love the app and appreciate all the effort that has made it the best in class. But as AxureMakesMeDrink says, my/our jobs are on the line.

I’m tasked with delivering prototypes that simulate applications. That’s not possible with Axure RP 8.

Regards,
Kiernan


#13

Hello!

Hmm, it sounds like you’re running into issues with loading times while viewing your prototype. To confirm, is it specifically when loading the prototype in the browser that is slow, or is it also slow on the canvas? Is the repeater itself particularly large as far as the number of rows and columns, or does it contain anything like large images or dynamic panels with many states? Aside from the repeater, is the rest of the page fairly widget-heavy?

We have some performance improvements coming up in the next release that should help in general, but if you’re able to attach a copy of the affected .rp file (or a similar sample one that shows the same issues) either here or via email to support@axure.com then that would help to investigate and determine if there’s something specific about the page setup that we can file for optimization on our end. Thank you!


#14

Hi Alyssa_Axure,

Thanks for the reply. I must confess to a rash reaction here. I think that the performance issue may have been caused by Sketch heavy imports.

See my reply in this thread about the Sketch Axure plugin (or is it Axure Sketch?).

Cheers.


unlisted #15