What's your average time to build an ISO?

P

pmikep

Active Member
Or maybe better, what can I do to speed up NTLite processing? Or "What's the bottleneck?"

It takes my computer about 25 minutes to trim a Win7. And that's starting with a trimmed iso, with only one edition, with updates already applied.

I know that there are too many variables to get a good answer. To be consistent, we all would have to start with the Win7+SP1.iso and then use one of Clanger's barebone presets to maximally exercise NTLite.

But I noticed, while doing a bunch of builds lately, that my CPU rarely goes to 100%. (Old AMD Quad Core, running 3.5 GHz.) And my Hard Drive light rarely stays on continuously. (RAID 10, with a sequential write in the 300's - although random writes are typical for a hard drive.)

That is, it doesn't seem like the bottle neck is my CPU or my hard drive.

What else could it be?

If it is my hard drive, then I presume that a SSD would speed up NTLite by a factor of 10?

Not that I plan to make a life out of 'Liting. But curious.
 
I would put the most data intensive folder on C(or whatever the fastest drive is) and the least on the raid because the mount folder may give better esults with 1 head, faster read and write times. Ideally i would have source mount and scratch folders on their own drive.
 
pmikep said:
@nuhi Respectfully, I think you're looking at this too short term. And perhaps focusing on the wrong users. You should be focusing on YOU and the long term benefit of this.

For example, let's say it takes you a month (okay, two) to optimize NTLite so that it's 50% faster. Forget about the time saved for the few of us who obsess with builds for a week. YOU (but also ultimately the rest of us) will benefit in the future because it will take you only half as long to test NTLite. The month or two you spend optimizing it now will speed up development later. You will quickly overcome any delay in removals once a 2x faster NTLite is working.

And since you will probably be deveoping NTLite for another 5 to 10 years, investing two months now is nothing compared to the years you'll save not having to watch the Progress Bars in NtLite.
Click to expand...
I may have replied to this, but I cannot find my reply, so here it goes potentially the same point again written shorter:
At first you are correct regarding the testing speed. But, finding issues in parallel processing, or in general any kind of optimization, which inevitably complicates the code, will increase the debug time, thus negating all of the benefits from my perspective.
Airplanes, Mike...oh you are my English teacher from the emails :)?

Faster disk for Scratch location.
 
I suggest you to first integrate all the updates and dont touch anything else, not even clean updates backup since this may break something. Then save this image, which is the process that will take the most time. Then use this image as a base to remove and configure things, so if you have to start again you dont have to integrate the updates again.
 
Yeah, I do that. (Except I let NTLite clean up the updates. The factory SP1 iso doesn't keep the old files. And the smaller the image, the faster it loads. (It took me while before I realized that I could trim out the other editions in my new Base image and save time not removing them each time in a final build.))

Well, as nuhi said, for most people, a faster NTLite probably wouldn't make much difference. It's only when you're tracking down an incompatibility that you wish it would run faster. But my Win7 desktop is running fine now - very lean - so I think I'm done for a while.
 
pmikep said:
Yeah, I do that. (Except I let NTLite clean up the updates. The factory SP1 iso doesn't keep the old files. And the smaller the image, the faster it loads. (It took me while before I realized that I could trim out the other editions in my new Base image and save time not removing them each time in a final build.))

Well, as nuhi said, for most people, a faster NTLite probably wouldn't make much difference. It's only when you're tracking down an incompatibility that you wish it would run faster. But my Win7 desktop is running fine now - very lean - so I think I'm done for a while.
Click to expand...

I used to always check the clean updates backup but I had a problem once that was solved by not checking this when creating the base image, thats why I leave it turned off when creating this base image. Ofc I turn it on when tweaking and removing it.
 
Yeah, I figured you wouldn't have suggested it if it hadn't fixed something for you. Do you remember what it fixed?

I wonder if it was more of a prolem with NTLite removing something it shouldn't have from the main Windows structure? 'Cause if I understand it right, the old files get parked somewhere in case needed for a roll back. (And so should be out of the picture during install.)

In any event, I only do the Convenience Rollup and an mp4 KB. So hopefully not too troublesome.
 
pmikep, 1 option i am looking at is using an nvme drive and getting ntlite to load and do everything on that drive.
 
Ahh... quoting nuhi from the thread that you linked: "But careful about update cleanup, it's always best be done with removals so you use latest engine to clean it, and keep your integrated updates base ISO copy without tampering at all."

So then it appears that it is not so much keeping the old trash around as it is that NTLite might not empty the trash correctly.

Okay. Well, fortunately, I ended up deleting my base iso, so had to use the latest NTLite to build it. Since I cleaned it with that, I'm probably doing better than I might have. But since cleanup is done after removals, I can see how it might be better to remove first, then clean up.

The only downside is that it makes the base iso a little larger - but what's a few seconds of copying files in the scheme of things.
 
pmikep said:
Ahh... quoting nuhi from the thread that you linked: "But careful about update cleanup, it's always best be done with removals so you use latest engine to clean it, and keep your integrated updates base ISO copy without tampering at all."
So then it appears that it is not so much keeping the old trash around as it is that NTLite might not empty the trash correctly.
Click to expand...

Would it work the same using a captured wim that had updates installed when it was running? Would i be better keeping the Software Distribution folder and not doing any cleanups sor NTLite can do its thing or remove it as per a wimscript.ini file?
 
Last edited:
Clanger said:
Would it work the same using a captured wim that had updates installed when it was running? Would i be better keeping the Software Distribution folder and not doing any cleanups sor NTLite can do its thing or remove it as per a wimscript.ini file?
Click to expand...
If you are adding updates to a captured wim, i think the process should be the same.
 
The updates would already be installed on the captured wim because i want everything installed and not pending. Its going to be 1 install, add updates and .nets, Sysprep, Capture, Import Capture and Shrink with NTLite - Save changes. What Nuhi and pmikep say makes sense.
 
Apologies for bumping this old thread, but I came across a revelation recently that thought others might find useful in regards to build speeds.

I noticed that using 8.1 as a host to create my Windows 7 custom image was cutting a lot of time off building.

Win 7 host = 43 minutes
Win 8.1 host = 8 minutes (!)

I put this down to DISM version changes/improvements on host machines. 32-bit or 64-bit gave similar improvements. BTW if you don't have an 8.1 license to hand you can use Embedded 8.1 (Evaluation). It is my host of choice and works perfect for building. I have only tried building Windows 7.

Thanks!
 
As this is the only topic I could find on this matter, I will bump it. Sorry.
Windows 10: 2 min 25 sec on an AMD 5950X with SSD. Source on a 4x10TB stripe volume HDDs
Capture.PNG
 
30 seconds isnt much of a saving with ssd over hdd, dont bother changing ssd's, stick to your hdd's then.
 
Clanger said:
30 seconds isnt much of a saving with ssd over hdd, dont bother changing ssd's, stick to your hdd's then.
Click to expand...
I am too tired it seems.
Source and temp were on SSD but the resulting ISO was still on the stripe of rust.
Changed the ISO location to be on the SSD also and got 1 minute 50 seconds. So another 10-13 seconds shaved.
SSD is a nvme PCIe 4.0
Was reading that some users in this topic were getting 20+ minutes, so me with my 2 minutes I am happy.
 
You must log in or register to reply here.
Back
Top