I have read a little guide that I have found on internet against the use of Macro in qlikview.
There you go some points:
The following are some reflections you should be aware of when you start in-cluding macro statements in your application.
1) Running a macro automatically deletes all caches, undo-layout buffers and undological operation buffers and this in general has a very large negative im-pact on performance as experienced by the clients. The reason for deleting the caches etc. is that it is possible to modify properties, selections from the mac-ros, thus opening up for conflicts between the cached state and the state that was modified from a macro and these conflicts will practically always crash or hang the clients (and in worst case; hang or crash the server as well).
2) The macros themselves are executed at VBS level while QlikView in gen-eral is executed at assembler level which is thousands of times faster by de-fault. Furthermore, the macros are single threaded synchronous as opposed to QlikView that is asynchronous and heavily threaded and this causes the macros to effectively interrupt all calculations in QlikView until finished and thereafter QlikView has to resume all interrupted calculations which is a delicate process and very much a source (at least historically) for deadlocks (i.e. QlikView freezes while the macro is still running, without any possibility that the macro will be finished).
3) While QlikView is increasingly optimized in terms of performance and sta-bility, the macros will always maintain their poor performance and the gap be-tween genuine QlikView functionality and the macros will continue to in-crease, making macros less and less desirable from a performance point of view. This fact combined with the above fact that the macros tend to under-mine all optimizations made in QlikView calls for severe negative tradeoffs as soon as macros become an integral part of any larger application.
4) The macros are of secondary nature when it comes to QlikView functional-ity - first all internal basic QlikView functions are run and tested and thereafter the macros are run and tested which effectively means that macros will never have the same status or priority as basic QlikView functionality - always con-sider macros as a last resort but nothing much else. Since the automation API reflects the basic QlikView in terms of object properties etc., the macro content may actually change between versions making this a very common area for migration issues. Once a macro is incorporated in an application, this applica-tion has to be revisited with each new version in order to make sure that the macros were not affected by any structural changes in QlikView and this makes macros extremely heavy in terms of maintenance.
5) Only a subset of macros will work in a server environment with thin clients (Java, Ajax) since local operations (copy to clipboard, export, print etc.) are not supported, though some of these have a server-side equivalent (e.g. Server-SideExport etc.) that is very expensive in terms of performance with each cli-ent effectively affecting the server performance in a negative way.
At the end of the day ... Macros they can be useful but probably is better to avoid them. I mean, for me it can be a very good thing because there are quite difficoult to implement and there is no debug as well.
What do you think? Do you often use macro on qlikview job?
In addition to what you mentioned, not all macros work in all clients: some of them do in the IE Plugin but does not in the Ajax.
As a general rule, I always try to avoid macros as much as I can. In older versions of QlikView, where actions were not featured, some of these macros were required to perform very basic tasks (such as set a value in a variable or minimize any object). The support to these macros is very limited (if any) as well.
And usually, most of the tasks can be performed with the right click of the mouse (exporting, changing chart properties).
I can't give a complete or authoritative answer, but your information does sound heavily biased. If you aren't careful, you can always come up with code that will completely buzzkill performance. This will be true whether you're using VBS, Java, SQL or TBD. The points on whether the processing is done in a particular threading model or interpretted or "compiled" is ridiculously overblown, considering the architecture of the operating system.
I adopt a simple philosophy in that if I can do something without using a macro, then I will. However, I find that sometimes I have no choice.
Two things I would say are that (1) while actions can be great, if you have more than 1 defined then be aware that they are fired in parallel NOT serially so dont rely on a previous action having completed (2) although a macro can be inefficient (for reasons of clearing caches etc) it is not much of an issue if it is being fired on the OnOpen event.
.png "Miguel_Angel_Baeyens"){kind=avatar}
