2. Simply supply the wixpdb instead of the wixout files in your command-line.

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Monday, May 19, 2008 5:24 PM
To: Rob Mensching
Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] really slow using pyro

 


1. ok.. I'll bite.  How would I override the default BinderFileManager in an 
extension?  Can you point me at an extension that overrides a part of the WiX 
system in a way that is similar to what I'd have to do? 
2. How can I use the pdb instead?  Is there a cmdline argument to pyro for 
that? 

Kelly 





Rob Mensching <[EMAIL PROTECTED]> 

05/15/2008 08:54 PM 


To

Kelly Leahy <[EMAIL PROTECTED]> 


cc

"wix-users@lists.sourceforge.net" <wix-users@lists.sourceforge.net>, "[EMAIL 
PROTECTED]" <[EMAIL PROTECTED]> 


Subject

RE: [WiX-users] really slow using pyro

 

                




“safe” is one way to look at it.  “correct” is another.  <smile/> 
  
We can look at adding a switch to make it easy, but you can actually get what 
you want right now.  You could implement an extension that overrides the 
default “BinderFileManager” and implement the CompareFiles() method using the 
method you describe.  You can see the default BinderFileManager does a byte by 
byte comparison. 
  
Also, I noticed that you were using .wixouts to build your patch.  I would 
recommend using the .wixpdb instead.  That will actually have all the necessary 
information to get much faster comparison (when the switch is finally 
implemented). 
  
From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 20:33
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: RE: [WiX-users] really slow using pyro 
  

I'm a bit suprised that it is doing this comparison for every file.  Is it just 
to be safe?  Could we add a switch that allowed it to do slightly less safe 
comparisons (i.e. I can guarantee that if two files have the same date, size, 
and name, that their contents are the same (or at least I'm willing to take 
that risk)). 

Wouldn't that speed up comparisons considerably? 

Kelly 


Rob Mensching <[EMAIL PROTECTED]> 

05/15/2008 08:19 PM 

 


To

Kelly Leahy <[EMAIL PROTECTED]> 


cc

"wix-users@lists.sourceforge.net" <wix-users@lists.sourceforge.net>, "[EMAIL 
PROTECTED]" <[EMAIL PROTECTED]> 


Subject

RE: [WiX-users] really slow using pyro


  

 

                





I talked to Peter.  For a product with ~2,000 - 3,000 files 10 minutes is 
reasonable.  Pyro is diffing all of the files in your product looking for 
different ones and that takes time.  
 
I noticed that you are using Includes all over the place.  Instead, you could 
use Fragments and get improvements in the compile steps and also do filtering 
at the Fragment level during patching. 
 
From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 12:01
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] really slow using pyro 
 

10 minutes running pyro, 2 minutes running the 'light' command line that builds 
the original msi's. 

Were you able to get the makefile, or do you want me to paste the command lines 
into an email for you? 

Kelly 


Rob Mensching <[EMAIL PROTECTED]> 

Sent by: [EMAIL PROTECTED] 

05/15/2008 10:04 AM 

  

 


To

Kelly Leahy <[EMAIL PROTECTED]> 


cc

"wix-users@lists.sourceforge.net" <wix-users@lists.sourceforge.net> 


Subject

Re: [WiX-users] really slow using pyro



  

  

 

                





One more question:  can you give me an idea of the time spent building MSI vs. 
building MSP?  Basically, I’m looking for a bit more details about what “long 
time” means.  <smile/> 

I’m not the patching expert but Peter is back from vacation and I’ll make sure 
he gets this thread tonight. 

From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 15, 2008 09:14
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] really slow using pyro 


Sorry, I was braindead last night and it didn't even occur to me that knowing 
the version and what I'm doing might be useful information :( 

0. tried that - didn't seem to tell me much of anything. 
1. 3.0.3419 - I'll try a newer build today. 
2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t 
mgalfa Update1\Build\USA\DiffRTM.wixmst 
(entire makefile is attached) 
3. all files are local 

other info: 
running Vista x64 Business on a quad-core machine with 4gb RAM and mirrored 
HDDs using hardware RAID. 
not much else going on while building (I've been giving it the full machine). 

Patch.wxs file, Product.wxs file, .wxi's, and makefile attached.  The wixproj 
contains the RTM folder's contents.  The Update1 folder mentioned in the 
makefile is nearly identical, with only differences being in content and the 
definitions in the defines.wxi (also attached here). 


Any recommendations would be greatly appreciated - and if there's anything I 
can do to help repro / debug, I'd be happy to do so, assuming it's within my 
capabilities or relatively close to them. 
Kelly 


Rob Mensching <[EMAIL PROTECTED]> 

05/14/2008 11:52 PM 

  

  

 


To

Kelly Leahy <[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 
<wix-users@lists.sourceforge.net> 


cc

        

Subject

RE: [WiX-users] really slow using pyro



  

  

  

 

                





0.  I assume you’ve tried passing the “-v” switch for verbose?  (I’m not sure 
there is much wired up to it). 

1.  What version of WiX v3 are you using? 

2.  What is the command line you’re passing pyro? 

3.  Are all of your MSIs and files local (not on a network share)? 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Wednesday, May 14, 2008 21:04
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] really slow using pyro 


When using pyro to build our msp's, it takes a very long time to build 
(approximately 5 times as long as building our original installer).  While this 
still isn't that long, it's very frustrating when we're trying to build and 
test our installs! 

Am I missing something easy that will make the builds of our patches run much 
faster?  What's actually going on during the 'pyro' processing?  Is it the file 
compares that could be taking that much time?  BTW, the patch in question ends 
up only being about 14K in size, and there's only 1 file out of about 960 that 
is different, and that file is very small (several K).  The two installs that 
are being compared are around 80MB in size when built into the MSIs, and are 
about 150MB uncompressed, I think. 

Is there any way to tell the pyro tool to tell me what steps are taking the 
most time so that I can try to understand if there's some optimizations we can 
do to improve it? 

Kelly 

**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**************************************************************************************
 


**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**************************************************************************************
 -------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**************************************************************************************
 



**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**************************************************************************************
 



**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or opinions
upon which reliance may be made by the addressee or any other party,
and it should be considered to be a work in progress. Unless otherwise
noted in this email or its attachments, this communication does not form 
a Statement of Actuarial Opinion under American Academy of Actuaries guidelines.
**************************************************************************************
 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to