Hi, 

I've just updated from version 1.7.0.0 to 2.1.1.0 using the MSBuild Task. I'm compressing arround 100 js files to one minified.js and the time for that jumped from around 3 secs to 30-40 sec with the new version.

Is there anything I can do about that or did I do something wrong?

Thanks a lot for your work!

hmm. that is interesting.

so it seriously only took 3 seconds to min/bundle 100 js files with v1.7?

Yes.. but I confess I have not cared about the compression settings yet with the new version. And it's only 80 files, not 100. And even less then 3 secs with 1.7. Never noticed compression actually before ;)

Details:

http://pastebin.com/U9FHUufy

hmm. love the output dump. thanks heaps for that.

First of all, are you using the .NET 2.0 or .NET 3.5 dll for 1.7?

I'm wondering if it's an issue with some .NET 2,0 code. hmmm.

Would it be possible to get a zip of as many of those js files if possible?

Thanks for the fast replies! This thing is quite weird. Maybe it's just my computers fault or harddisk or whatever.

Here is a package with some jquery ui files and some larger libraries I used in my project. Extract the stuff to C:\yui-compress then you can run the bat files directly. 

http://techcrawler.riedme.de/upload/yui-compress.zip

If I remove the large .js files (starting with a number) everything runs fine and quite fast with both versions. 2.1. is a bit slower though. But if those js files are there, every 2nd file access seems to take a while with the new version.

Sorry I've no other computer here to test if it's my systems fault.
It's also not really a big deal for me, as I'm just compressing the js files for the release builds now.

Bit of a weird one.

Using your example (excellent btw, fully working examples of a problem, just what we need!), if I cut them down to a single large file each, there's nothing in it between the old and new.  New was slightly faster in fact, but not so you'd notice really, but suggests its having multiple files that is the problem.....but the code for multiple files is not overly complex, basically looping around doing a File.ReadAllText, passing that to the compressor, and appending the compressed results to a string builder.

I don't think it is wildly different to the 1.7 code in that respect.  One noteworthy change is that it was .Net 3.5 before but is now 2.0..but I'm not aware of file I/O being particularly better in later versions of .NET.

I guess a thing to do would be to compare the 2.0 version (there was a separate one back in the day) of 1.7 to the 2.x version and see how they compare.

I'm a bit swamped at the moment but will try to look at this more over the next week or so...

Found the little bugger!

In 1.7, a new compressor was instantiated per javascript file.

In 2.x, a new compressor is instantiated per msbuild task call.

There is a class level variable (_globalScope) in the compressor which needs to be initialised per compression call - this happened "naturally" in 1.7 due to a new instance every time, but not in 2.x with a single instance.

The result was an every growing array of script or function scopes to visit as more and more files were compressed...which increased the compression time overall as we have seen.

For a list of 20 files (well, the same file 20 times), the number of calls to a key function, (Munge) went from 18,140 in 1.7 to 190,280 in 2.x - EPIC FAIL :/ 

It is now back down to 18,140 in both cases.

Thanks Epstone for your perfect example of a bug report - a self contained example of a problem.  Saved a lot of time in investigating this issue.

Thanks also to Jetbrains dotTrace, which put a bloody great "look here" pointer to the offending code :)

Have checked in a fix so you can grab the latest sources and build yourself a faster 2.1, or wait for PK to issue an "official" release

Thank you freeranger, really great news, your welcome! I will grab the new version and definitly enjoy the compression speed again. :)

you're welcome.  You'll have to wait for PK to pull the finger out to do the release first though :)

@Epstone - new version is now out. can u nuget update please and report back into this thread, please?

Yeah, great work! Compression duration went down from over 18 secs to 0,76  :)  (I'm back on my quadcore...)
And...... it's going to run on every f6 again ;)

I downloaded directly from the page here, I'm not using the nuget package. Hope thats ok too.

Excellent news and well done on spotting the deliberate c0ckup @}

Is it ok do download direct from the page?  Of course it is - I have no truck with nuget either but "certain people" are obsessed with it :)

cheers!