0

ClickOnce Deployed .Net 4.5 WPF application. Tests runs on Windows 7 & Windows Server 2008 R2. Memory/CPU/IO (writes to local database) intensive process takes 8 minutes on 2 test machines and ~ an hour on every other machine (both of the "fast" machines are older Windows 7 machines). Virtual / physical, 32 / 64 bit makes no difference; one of the "fast" machines is 32 bit, the other is 64 bit (both have the same memory & processor specs, but so does one of the "slow" machines). The 32 bit machine actually runs a bit faster. The newer 64 bit Windows 7 machines with 3X the memory and faster processors with more cores than the "fast" 32 bit machine recorded some of the slowest times.

Every portion of the process (creating lots of objects, sending insert statements to the local database, etc.) is takes uniformly longer on the "slow" machine. IOW, it's not IO vs. CPU.

Fast:

  • 32 bit, 4GB RAM, 2X4 core procs
  • 64 bit, 4GB RAM, 2X4 core procs

Slow:

  • 32 bit, 4GB RAM, 2X4 core procs (The only real difference other than, e.g., different hard drive manufacturer between this one and the fast one above is that this machine has twice the L2 cache as the fast one)
  • 64 bit, 12GB RAM, 2X6 procs (multiple machines tested with these specs and they tested close to slowest)
  • 64 bit, 4GB RAM, 1X2 core proc (virtual)
  • 64 bit, 8GB RAM, 2X2 core procs (Server 2008 R2 with faster SCSI drive)

We have a 32 bit machine here that is almost exactly the same as the "fast" 32 bit machine. The only real difference (other than, e.g., different hard drive manufacturer) is that the "slow" machine has twice the L2 cache as the "fast" one. That "slow" machine takes over an hour. Thus, it seems certain that it's not a hardware issue.

Nor does it seem to be an issue of some other running process; things that I've looked at:

  • Machine.config: copied from "fast" machine to "slow". No difference.
  • Hard Drive Encryption: Some machines have hard drive encryption turned on, some don't. One of the "fast" machines lacks encryption, but some of the slow ones have it.
  • Real time virus protection: Most machines have this running (including the "fastest" machine and some of the slowest).
  • The process is not network dependent; the entire process is local.
  • Pagefile settings: Duplicate settings between "fastest" and one of the "slowest."
  • Processor load balance: Looked at processor load balance (only by viewing task manager). No obvious difference.
  • Build platform target: Made an X64 only build thinking that would make the 64 bit machines run faster (maybe they were running the app on WOW64?). No difference. Verified the difference in the built exe using ManifestModule.GetPEKind.
  • Compared differences in registry settings for a ClickOnce related value named "OnlineAppQuotaUsageEstimate." That value was lacking on the "slow" machine, but when I added it under the keys that it existed under on the "fast" machine, there was no difference. Wouldn't seem to be related in any case.
  • Service packs / patches: Everything same here.
  • Ran NP Profiler. Difference between "slow" and "fast" machines: the "fast" machine takes longer to run the threads that don't do as much work, but less time to run the heavy lifting threads. There is no single thread / method that stands out as the culprit. One thing I did notice is that a log entry in a file takes measurable time on the slow machine but no measurable time on the fast one. That lead me to closely examine the hard drives and caching, but there was no difference other than the L2 difference noted above (slower machine has twice the caching as the faster).
  • [edit] Created a small console app that does some similar things (string/list manipulation along with writing to local DB). Same exact proportional results.

All indications are that there is some windows configuration on the 2 "fast" machines that is different from the "slow" machines. Looking for suggestions about what the difference may be; I don't think there's any kind of tool to point at 2 different machines and show the differences. I can't look at registry export differences; there would be 500K of them.

Community
  • 1
  • 1
dudeNumber4
  • 4,217
  • 7
  • 40
  • 57
  • 1
    How about service packs and patches? That is where I would look. – paparazzo Nov 25 '13 at 16:16
  • I agree with @Blam. Also, maybe different services running?? Maybe add some code into your program to update a log at different points throughout execution... Maybe you can see if there's a specific area of code that's running slow and maybe that can tell you something... Just random ideas. Good luck! – John Bustos Nov 25 '13 at 16:44
  • @Blam: Added two bullets to things I've tried. Should've mentioned already. – dudeNumber4 Nov 25 '13 at 18:07
  • Have you tested running the apps outside ClickOnce i.e. a stand-alone executable? – NothingsImpossible Nov 26 '13 at 23:08
  • @NothingsImpossible: It's a *massive* solution (~35 projects). It can't even be published manually - it will only run when installed from an automated build. You make a good suggestion, though. I may embark on a separate solution, build that as a regular executable and test it that way. – dudeNumber4 Nov 27 '13 at 17:48
  • @NothingsImpossible: Added stand-alone executable to list of things looked at. – dudeNumber4 Dec 10 '13 at 16:53
  • I'm now pretty sure this is due to [False Sharing](http://msdn.microsoft.com/en-us/magazine/cc872851.aspx). See especially "It doesn't scale well when the concurrency level is increased by running on more powerful hardware." – dudeNumber4 Jul 24 '14 at 19:33

1 Answers1

0

Start the NGEN service on the "slow" machine. It's a Windows Service.

Tim P.
  • 2,903
  • 24
  • 26
  • Studied up on NGEN, tried this method (http://stackoverflow.com/questions/443955/is-it-possible-to-use-ngen-with-clickonce-deployment), nothing. Manually installed the app from command line using NGEN, saw it do it's thing, nothing. Good suggestion though. BTW, it's not a service you can merely start (it will just shut back down). – dudeNumber4 Dec 06 '13 at 16:57