Be sure to review our Idea Submission Guidelines for more information!
Submission GuidelinesWhen you have an Alteryx workflow open, Alteryx seems to by default try to keep you up to date on what might be happening with your data when it runs through your workflow. So if you for example add a misconfigured tool (a filter not connected to an input) and click somewhere on the canvas it'll presumably try to compile the code and then figure out that the new tool is misconfigured and it'll tell you why. A major thing it does seems to be that it tries to figure out if macros included in the workflow have changed and to take such changes into account so that it can notify you if there's a problem somewhere e.g. with the macro's output schema or whatever. I know it's doing this kind of thing because the moment I add a macro to the workflow I'll have to spend a 15-20 second 'tax' every time I touch the workflow canvas, a formula, when I click on a join, etc. Sometimes it's 30 seconds, sometimes you get lucky and it'll only be 5 seconds. This delay is by now from my perspective considered a fixed cost of adding a macro to a workflow. I'm assuming similar processes also take place in the context of other dependencies (main one probably being queries inside input tools) and that they may also cause problems for similar reasons.
I'm assuming part of the reason for the long delays is that the macro repository where we usually save macros in my organisation is saved in a server location which is close to the Alteryx server executing the in-production workflows/macros, but not close to me when I'm developing in my office. Yes, I could save the macros I develop elsewhere (locally) and then only save them in the repository when they're 'complete' (...we all know exactly when that's the case; we're never in doubt about that, right? ...and you'll still have problems if you need to modify a workflow which includes macros later, even if you're not touching the macro itself). I'm actually doing that in some contexts where the above user experience has been frustrating enough to justify such a step, and I'm always trying to find ways to just outright kill Alteryx' live connection to the macro (e.g. by caching the output) if it's not critical. But these things are not solutions, they're poor workarounds some of which are adding complexity and the potential for errors as a result of a problem which really shouldn't be a problem.
It would be desirable to have the option to pause these kinds of 'background processes'/'semi-live compiling'/'whatever', make Alteryx do this kind of thing less frequently, add an 'only update meta-data when running' option, or some fourth option of a similar nature. Debugger-mode is implicitly always on, why not give the option of turning that off if the user figures s/he can handle that? Give me the error when I try to run the workflow, don't try to have the software figure out if the code will run with an error every time I even touch it - this is not always helpful, it's in some contexts causing a huge waste of developer time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.