PDA

View Full Version : IS12 and InstallScript CAs



sks2004
06-09-2006, 05:50 PM
I converted our IS-11 Basic MSI project to IS-12...no problems...the conversion went without error and the project built successfully.

Although, when I run the IS-12 built setup.exe, all InstallScript Custom Actions within the UISequence run extremely slow...very very slow. Also, within the ExecuteSequence, the 'Cancel' button won't effectively cancel the installation.

All InstallScript CA performance seems to be hindered drastically...at least for me.

LSyracuse
06-09-2006, 06:10 PM
I've noticed the same thing. I wondered if it was just me, but pretty much everything seems to run slower in IS12 on my systems - building and installing.

Lou

Christopher Painter
06-10-2006, 03:12 PM
I noticed that it seemed to take a long to to invoke a CA that called MessageBox. My guess is they did some tricks to compress the runtime and are paying a performance hit when initializing it. If you have many seperate CA's being invoked this could add up to a sizable amount of time possibly.

sks2004
06-12-2006, 09:59 AM
Even with one InstallScript CA, the performance is very slow. It doesn't seem to be the loading of the InstallScript DLL engine -only-, but the actual InstallScript code itself. Small InstallScript CAs execute quicker than larger ones.

It is unacceptable performance...I could never ship one of our products with this type of performance hit. To reiterate, IS-11 generated InstalLScript CAs run quick within the UISequence...IS-12 generated InstallScript CAs run very slow within the UISequence.

I hope something can be done about this.

sks2004
06-12-2006, 10:35 AM
I've tested, and realized that this issue is much more prevalent on W2k machines than it is on Wxp machines. It is slow on both, just not as slow on Wxp.

MartinMarkevics
06-12-2006, 03:49 PM
In IS 12.0, each custom action loads a new instance of the script engine, whereas previous versions of InstallShield only loaded the engine (and script) only once. So, for each custom action in your setup, you do now incur this extra overhead. However, the benefits far outweigh this overhead.

While you may see a slight delay in running an InstallScript CA, you also have to consider the fact that we removed the requirement of ISScript.msi for each setup and also removed the engine startup & cleanup custom actions. So, loading the CA takes some time, but a number of things prior to the actual CA execution have been removed altogether. Granted, engine startup\shutdown for example, now occurs inside of the respective custom action rather than earlier in the sequence. So, you incur the same overhead, just at a different point.

That said, what kind of “unacceptable performance” do you see on Win2K? Are we talking a matter of seconds, 10s of seconds…? Are you comparing apples to apples here (meaning similar machine configurations)? It stands to reason that smaller InstallScript code will run faster that larger scripts. Less code to extract, load and manage will always execute faster. No secrets there.

In regards to Christopher’s point… We do compress the engine (ISSetup.dll), which substantially cuts down on the size. In our testing, I saw very little performance impact as a result of the compression, but no compression comes without tradeoffs. If you are willing to runs some tests, I’d be happy to send you an uncompressed version of ISSetup.dll to see if this improves performance. Just send me a Private Message and we’ll go from there.

Anyway, I'm not saying that we can't improve the performance. I'm sure that given time, there are plenty of more optimizations we can and will make. In general though, almost all of the feedback we’ve gotten is that if it’s a choice of size vs. speed, size is far more important to people (within reason of course).

MartinMarkevics
06-12-2006, 04:11 PM
Lou,

In regards to your comment:


I've noticed the same thing. I wondered if it was just me, but pretty much everything seems to run slower in IS12 on my systems - building and installing.

What runs slower (besides the InstallScript CAs) in the IDE or build? In general, the build process should actually be a little faster in IS 12. I don't have specific numbers, but there was an effort made to increase performance of various pieces of the product (including the build). If there are other performance issues that you have specific concerns about, let us know and we'll fix them.

Christopher Painter
06-12-2006, 05:30 PM
I made an InstallScript CA that does nothing except return ERROR_SUCCESS and called it 10 times from a VBScript CA using DoAction. I logged the start and stop time and found that it takes apx 1.5 seconds per CA ( 20 iterations took 30 seconds ) on my machine to initialize the engine.

For my purposes this is fine as I rarely have CA's, but if someone was to have alot of little CA's broken out and spread through an install I could see the pain. As it stands right now I have one particular install that could call maybe a dozen or so CA's. If performance becomes bad I'll break it into 1 CA that conditionally calls various functions to save on initialization time.

michael.s.white
06-21-2006, 05:01 PM
I made an InstallScript CA that does nothing except return ERROR_SUCCESS and called it 10 times from a VBScript CA using DoAction. I logged the start and stop time and found that it takes apx 1.5 seconds per CA ( 20 iterations took 30 seconds ) on my machine to initialize the engine.


For me this issue has cause me to roll back to using 11.5. We have hundreds of lines of code in Installscipt that just will not work on 12.0. Adding them all to one Script may work but that would be a nightmare to do and to manage. At this point, if I have to do any more custom actions they will be done in C++. And IS 11.5 is the last version we will upgrade too.

Christopher Painter
06-21-2006, 06:48 PM
How many custom action entry points do you have?

MartinMarkevics
06-21-2006, 11:30 PM
Michael,

Just to further understand your issue here... How many InstallScript custom actions do you have? What exactly is the cause of your concern, the performance of the individual CAs (~1.5 seconds for an empty CA as Christopher pointed out) or something else?

michael.s.white
06-22-2006, 11:36 AM
Michael,

Just to further understand your issue here... How many InstallScript custom actions do you have? What exactly is the cause of your concern, the performance of the individual CAs (~1.5 seconds for an empty CA as Christopher pointed out) or something else?


We range from 1 action, to 6 when we start doing validations on SQL. But one action takes anywhere from 1 sec to 3 depending on the machine I test it on. Obviously the faster the machine the better the performance.

This delay makes the isntallations appear unprofessional. Since the majority of our buisness comes in through trials or sales demonstration, the installer behavior is extremely critical to our buisness.

The following is a excert of a log file I recently sent into support. Note that the custom action GetMediaType is a C++ DLL. This action runs at a signifigantly faster pace than the IS custom acions.


MSI (c) (48:B8) [08:29:26:464]: Doing action: ConfirmINSTALLDirMedia
Action 8:29:26: ConfirmINSTALLDirMedia.
Action start 8:29:26: ConfirmINSTALLDirMedia.
MSI (c) (48:84) [08:29:27:724]: Invoking remote custom action. DLL: C:\windows\temp\MSI474.tmp, Entrypoint: f5
MSI (c) (48!C4) [08:29:29:384]: PROPERTY CHANGE: Adding bINSTALLDrive property. Its value is 'TRUE'.
Action ended 8:29:29: ConfirmINSTALLDirMedia. Return value 1.
MSI (c) (48:B8) [08:29:29:454]: Doing action: GetMediaType
Action 8:29:29: GetMediaType.
Action start 8:29:29: GetMediaType.
MSI (c) (48:70) [08:29:29:474]: Invoking remote custom action. DLL: C:\windows\temp\MSI475.tmp, Entrypoint: DLL3
Action ended 8:29:29: GetMediaType. Return value 1.
MSI (c) (48:B8) [08:29:29:544]: Doing action: AddSlashINSTALLDirMedia
Action 8:29:29: AddSlashINSTALLDirMedia.
Action start 8:29:29: AddSlashINSTALLDirMedia.
MSI (c) (48:80) [08:29:29:884]: Invoking remote custom action. DLL: C:\windows\temp\MSI476.tmp, Entrypoint: f8
Action ended 8:29:31: AddSlashINSTALLDirMedia. Return value 1.
MSI (c) (48:B8) [08:29:31:544]: Doing action: ConfirmINSTALLDirectory
Action 8:29:31: ConfirmINSTALLDirectory.
Action start 8:29:31: ConfirmINSTALLDirectory.
MSI (c) (48:9C) [08:29:31:864]: Invoking remote custom action. DLL: C:\windows\temp\MSI477.tmp, Entrypoint: f7
MSI (c) (48!D8) [08:29:33:424]: PROPERTY CHANGE: Adding dirValid property. Its value is '1'.
Action ended 8:29:33: ConfirmINSTALLDirectory. Return value 1.
MSI (c) (48:B8) [08:29:33:484]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'.
Action 8:29:33: SetupType. Dialog created


I havent even gotten to my SQL screens yet to discover the time latency on those. They are already slow enough from all the SQL calls.

michael.s.white
06-22-2006, 11:39 AM
How many custom action entry points do you have?


Not sure what you are asking. Are you asking how many Installscript custom actions we have exported? for this project we have 13 but for some of our other products we may have double that number. There are also 11 other functions that are not exported.

Christopher Painter
06-22-2006, 11:48 AM
What I'm getting at is it's the invocation of the entry point ( exported ) function that causes the delay. Once your executing the script calls to the private functions don't cause a delay. Take the example you gave:

DoingAction: ConfirmINSTALLDirMedia
DoingAction: GetMediaType
DoingAction: AddSlashINSTALLDirMedia
DoingAction: ConfirmINSTALLDirectory

That would cause about a 6 second delay. Do you always call all 4 of these in a row? If you had one entry point CA ( like ProcessMedia ) that internally called 4 functions ( the four listed above ) you would save at least 4.5 seconds.

michael.s.white
06-22-2006, 12:06 PM
What I'm getting at is it's the invocation of the entry point ( exported ) function that causes the delay. Once your executing the script calls to the private functions don't cause a delay. Take the example you gave:

DoingAction: ConfirmINSTALLDirMedia
DoingAction: GetMediaType
DoingAction: AddSlashINSTALLDirMedia
DoingAction: ConfirmINSTALLDirectory

That would cause about a 6 second delay. Do you always call all 4 of these in a row? If you had one entry point CA ( like ProcessMedia ) that internally called 4 functions ( the four listed above ) you would save at least 4.5 seconds.

Thanks for the feedback


I have a couple issues with this method however.

- The exaample above uses a C++ DLL call for GetMediaType. This custom action is dependant on some string hadeling in the preceeding custom actions. I could get around this but would have to call the DLL from with the InstallScript.

- Even if I do combine them into one custom action it still take about 2 sec between each screen and this is not acceptable since we do alot of trials. And the Installer if the first impression for prospective clients.

- Also we have built in the ability to bypass validations. We use this to open up the install to work on unsupported installation. This would need to be coded into installscript where now it is as condition on the custom actions running.

- All of the changes this would require would cost alot of time. Time that at this point is better spent on converting the custom actions to C++.

Christopher Painter
06-22-2006, 12:22 PM
What is GetMediaType? Check to see if it's a harddrive/CDROM or something? I do that within InstallScript using WBEM's win32_logicaldisk class.

About your perception of speed... I've thought about this also. A two second delay in say the initialization screen before InstallWelcome is probably unnoticed and a two second delay in a defferred CA is unnoticed because they are happening within transactions that 1) the user already expects to take awhile and 2) have a progress bar / splash screen to distract the user

Throw that same two second delay between two dialogs in a sequence and suddenly it's `noticable`. If this really is such a huge problem ( and not just something to yell at InstallShield about ) then I'd refactor just those CA's into C++.

michael.s.white
06-22-2006, 12:52 PM
What is GetMediaType? Check to see if it's a harddrive/CDROM or something? I do that within InstallScript using WBEM's win32_logicaldisk class.

GetMediaType is just that. It is the API call to get what the drive type is. We use this to make sure the drive exists and that it is a local hard drive.

You use a WMI call? This should work but we try to avoid using outside objects since supporting these in an installer can cause problem.

Christopher Painter
06-22-2006, 03:22 PM
Yes, I agree. Dependencies are BAD. :)

Unfortuantly I'm working in a shop that makes me right VBScript CA's despite my objections. Fortunatly the ISScript Engine refactoring in IS12 is going to let me push IScript CA's forward and then I'll be able to use the native Win32 API call that you talk about.

We explored rewriting it all in C++ but InstallScript just brings so much to the table as a Domain Specific Language that it would cost alot more to do C++. More speed would be nice, but what I really want is something thats quick ( read cheap ) to develop and bulletproof.

sks2004
06-22-2006, 10:15 PM
I agree with michael s. white, the performance issue forces us to stay at IS-11.0. Too bad, because IS-12 fixes a number of bugs that I have had to workaround.

I'm confident something will be done to improve this problem...it is very simple to reproduce, and very evident...more-so on W2k platforms, but still unacceptable on WXP.

Working around this issue (putting all of your CAs into one, then calling each function, etc...) is not an exciting method...it is a workaround.

I am a quality assurance engineer first, installation developer second...IS-12 needed more use cases...more software testing.

Christopher Painter
06-23-2006, 07:42 AM
I agree with michael s. white, the performance issue forces us to stay at IS-11.0. Too bad, because IS-12 fixes a number of bugs that I have had to workaround.

I am a quality assurance engineer first, installation developer second...IS-12 needed more use cases...more software testing.

I'm suprised that a QA Engineer would choose performance over reliability. The IScript Engine that 11.5 and before used was just loaded with bugs. The performance issues in IS12 are not so much a matter of being a bug but more a matter of it's over all design.

It's been discussed here before that the performance issue is due to the fact that each CA must decompress and instantiate the scripting runtime instead of it being done once at the beginning of the installed and shared to CA's through DCOM ROT. The reason it is compressed because most user feedback has said that a smaller installation package is more important then a faster installation package.

michael.s.white
06-23-2006, 08:22 AM
I agree with michael s. white, the performance issue forces us to stay at IS-11.0. Too bad, because IS-12 fixes a number of bugs that I have had to workaround.


Yea that was the thing I was excited byt 12.0 also until these snags. But unfortunately the cost ended up not being worth it. They have responded to the bug I submitted so I know IS is considering the issue but it may be one where they are weighing the cost of changing this with the needs in the community.

Christopher Painter
06-23-2006, 08:59 AM
One thing that might help... I've seen it bounced around for consideration to have a Release setting that tells it to compress the ISSetup.dll or not. This way someone who cares about speed could say No and someone who cares about Size could say yes.

I'm not sure what percentage of the total delay is caused by the compression though. I will say however that I'm partly guilty of causing the compression since myself and several others beat up on InstallShield during the beta saying that the dll was too big.

bryanwolf
06-23-2006, 10:19 AM
Well, consider that the engine doesn't actually have a running instance beyond that of the custom a ction. While I agree that performance could be better, it's also not abysmal either. The plurality of users are familiar with or willing to accept installations that take upwards of 10 - 15 minutes (heck, some games and large applications take an hour or more to install), so while performance could be better I think it's a step in the right direction.

InstallScript is much more bulletproof, less prone to bugs, and in my opinion, much more powerful than it was in previous incarnations. Although there's a performance cost to those improvements, I think any QA department should be elated to see the engine as sturdy as it is.

But these are just my opinions :)

michael.s.white
06-23-2006, 11:02 AM
Well, consider that the engine doesn't actually have a running instance beyond that of the custom a ction. While I agree that performance could be better, it's also not abysmal either. The plurality of users are familiar with or willing to accept installations that take upwards of 10 - 15 minutes (heck, some games and large applications take an hour or more to install), so while performance could be better I think it's a step in the right direction.

InstallScript is much more bulletproof, less prone to bugs, and in my opinion, much more powerful than it was in previous incarnations. Although there's a performance cost to those improvements, I think any QA department should be elated to see the engine as sturdy as it is.

But these are just my opinions :)


I partially agree. while a lengthy isntallation process is acceptable. the screen transitions is the problem we can not accept. taking anywhere from 2 -20 seconds to go between screen is not only frustrating, it makes the installation look unprofessional.

The fact they finally moved away from the IS runtime was a key factor for us moving to 12.0 and i agree that QA is elated. Or more accurately the help desk is elated as they get stuck fixing the runtime issues.

But being a company who use trail installation to generate interest, the installation process is important to our buisness model.

Christopher Painter
06-23-2006, 11:12 AM
The 2 second load time I can understand, but what are you doing in a custom action between dialogs that takes 20 seconds? Are you connecting to a web service or something and waiting for it to time out?

I've had some CA's that look for successful database connections to turn on a feature if found or hide the feature if not found and I do alot of validation that the database exists and is running before I actually try to connect to it so I can avoid connection attempts that don't exist and the assoicated time cost of a failed connection.

If you could isolate the transaction that is causing the performance hit and calculate the delta from IS11 it would be very valuable. At this point we are talking about load time costs and we havn't done benchmarks on other transactions.

michael.s.white
06-23-2006, 02:01 PM
The 2 second load time I can understand, but what are you doing in a custom action between dialogs that takes 20 seconds? Are you connecting to a web service or something and waiting for it to time out?


It is just that our original design has up to 8 validations on some screens. We do everything from validating accounts to validating SQL connections and editions.

Which brings us back to the consolidation of checks.

bryanwolf
06-23-2006, 04:25 PM
Consolidation would likely help this a significant amount. I'm really interested to see if you could get some kind of difference between execute time in 11 or 11.5 versus what InstallShield 12's scripting engine provides.

At this point in time, I think we're operating purely on speculation. I would not be suprised at all if the runtime did increase; however, I'm interested to know if the increase is truely significant or if it is a matter of a couple of seconds.

Either way, I would probably suggest using singular InstallScript entry points.

From a design perspective, the current implementation is more similar to the way you'd author an MSI DLL. Even if you created an MSI DLL, if you had 8 different entry points, you would still be in a scenario where you could have a significant amount of overhead. Best case scenario, you might (and I don't know if this would work) get some kind of cache where the memory for the DLL may be loaded for subsequent calls - but I don't know that this would work because of the way Windows Installer extracts the DLL with a random name.

Really, it would be best to try to have a single entry point and use it as a dispatch method to call your C++ DLLs as necessary and/or other InstallScript functions in my mind.

Christopher Painter
06-24-2006, 09:34 AM
I don't think the caching would work because InstallShield puts the script resources for the functions and the engine resources in the same module. If you have merge modules with InstallScript CA's those functions are in a seperate DLL in the binary table and you could get your entry points mixed up.

sks2004
06-24-2006, 01:27 PM
I'm suprised that a QA Engineer would choose performance over reliability. The IScript Engine that 11.5 and before used was just loaded with bugs. The performance issues in IS12 are not so much a matter of being a bug but more a matter of it's over all design.

It's been discussed here before that the performance issue is due to the fact that each CA must decompress and instantiate the scripting runtime instead of it being done once at the beginning of the installed and shared to CA's through DCOM ROT. The reason it is compressed because most user feedback has said that a smaller installation package is more important then a faster installation package.

Our tens of thousands of field-customers have had very little installation issues. I opt for reliability then performance...but when the performance is poor, reliability means absolutely nothing, when the customer is frustrated and complaining about it. Back-door workarounds aren't the answer in any type of software developement.

The performance issue is a bug in the design, plain and simple.

sks2004
06-24-2006, 01:36 PM
The 2 second load time I can understand, but what are you doing in a custom action between dialogs that takes 20 seconds? Are you connecting to a web service or something and waiting for it to time out?

I've had some CA's that look for successful database connections to turn on a feature if found or hide the feature if not found and I do alot of validation that the database exists and is running before I actually try to connect to it so I can avoid connection attempts that don't exist and the assoicated time cost of a failed connection.

If you could isolate the transaction that is causing the performance hit and calculate the delta from IS11 it would be very valuable. At this point we are talking about load time costs and we havn't done benchmarks on other transactions.

1.) Create any type of InstallScript CA...doing a simple, quick task...and clone the CA.
2.) Insert 3 or 4 of these cloned CAs to a 'Do Action' on a 'Next' button...on any dialog.
3.) Compile/build, then test the performance on a W2K SP4 machine and WXP SP2 machine.
4.) Try this test again on a P3-800 Mhz/ 256 Ram machine, then a P4-3 Ghz/ 1 gig Ram machine...both OS types.

Christopher Painter
06-24-2006, 02:03 PM
This initialization transaction scenario is already well understood and has been discussed repeatedly. What I was asking for is to measure the performance of the engine beyond initialization.

michael.s.white
06-28-2006, 02:58 PM
Our tens of thousands of field-customers have had very little installation issues. I opt for reliability then performance...but when the performance is poor, reliability means absolutely nothing, when the customer is frustrated and complaining about it. Back-door workarounds aren't the answer in any type of software developement.

The performance issue is a bug in the design, plain and simple.


The response I am getting from support makes it seem like they are not treting this like a bug. They are using the two recomendation stated in this conversation. Consolidate custom actions or move them into the sequence. Ohh yea or convert them to another custom action type. Wonder if they will foot the bill for that endevor.

There is some customer satisfaction for you.

sks2004
06-29-2006, 09:43 PM
I'm hoping for a fix. We have already purchased an annual maintenance agreement for our seats...but can't use the latest release, IS-12, because of it's performance issues with InstallScript Custom Actions within the UISequence.

Christopher Painter
06-29-2006, 10:39 PM
There has been talk of having a build release setting where you can tell it to optimize for size or speed ( compression or no compression ) but beyond that I doubt there is much to be done.

StefanPaetow
07-03-2006, 09:20 AM
There's always the option of allowing customers to choose 'classic' behaviour... i.e. load the script engine in the beginning, and let it run until the MSI quits.

Customers will have to be aware that this will mean the addition of a load of custom actions to support that.

Stefan

bryanwolf
07-05-2006, 10:51 AM
The old engine behaviors and DCOM issues are not compatible with Windows Vista for the most part. As each OS comes around, the old engine model has a new plethra of security related errors. This means that if we did implement this type of logic, it would likely not target Vista or later operating systems or would do so at the installation developer's own risk.

Christopher Painter
07-19-2006, 12:24 PM
Our tens of thousands of field-customers have had very little installation issues. I opt for reliability then performance...but when the performance is poor, reliability means absolutely nothing, when the customer is frustrated and complaining about it. Back-door workarounds aren't the answer in any type of software developement.

The performance issue is a bug in the design, plain and simple.

Another user stumbles over to Community after being nailed by IDriver...

http://community.installshield.com/showpost.php?p=358506&postcount=1

sks2004
06-12-2007, 05:48 PM
Any ideas if this performance issue will be addressed within a future release?

Christopher Painter
06-12-2007, 09:00 PM
Not that I know of as I really havn't heard a whole lot of complaining on this subject in the last few months.

In my installs at work I hav an InstllScript CA that calls CoCreateObjectDotNet to JIT a class and invoke it. Once inside it invokes a webservice sitting on our application server which also often needs to be JIT'd since I typically just upgraded the server and the AppPool isn't online yet.

I usually takes about 3-4 seconds for all this to happen. If I click back and do it again it typically takes about 1 second since the client and server classes are already JIT'd.

No one has ever really complained about how long it takes, they just think it's cool that the install is performing a server check.

Is the InstallScript design perfect? Will it ever be as fast as say C++? Of course not. But I do think it's pretty good and fairly easy/possible to mitigate the initial startup transaction costs in terms of performance.

Sorry if we don't agree on this point.

sks2004
06-13-2007, 10:11 AM
I have a PM that keeps asking why the installer for last year's product is slick and super-fast, and this year's installer is not... when seemingly nothing has changed with the installation project (except of course, upgrading the installation projects from IS-11 to IS12).

I do use a good deal of InstallScript custom actions... I have for years. I like InstallScript, but if the load performance problems aren't solved, I'll be forced to convert all or most custom actions to C (and beg for dev time to do so), which will require gobs of time... our installations are complex by necessity; they do alot and include the kitchen sink ;).

I do appreciate your ideas and feedback, Christopher.

sks2004
09-25-2008, 03:19 PM
I wonder... has anyone found a workaround? I would love to bring InstallScript custom actions back up to speed.

I have noticed that if you have the InstallShield 2008 IDE running while you run your installation (not from within the IDE...); the performance is great. The IDE must load a separate engine, I'm guessing...

There must be a solution.