3

I've recently bought a Surface Pro 3 (Win 8.1, Core i7, 256GB Samsung SSD), mainly for .NET development and am disappointed at the performance.

As an example, performing a full rebuild of a medium-sized project using msbuild from the command line consistently takes roughly three times longer than on my three year old Lenovo X220T (Win7, Core i5, 128GB SSD, ESET NOD 32 Antivirus); ~3min 30s vs ~1min 10s.

I can't see any indication of neither CPU nor disc saturation when building. I've attempted to disable Windows Defender temporarily but that didn't make any difference. I've applied all updates from Windows Update, including the latest firmware update from January 2015, but that also made no real difference. I've tried to optimize the drive using the Windows built-in tools. No luck there either.

The only thing that I can think of right now that might be an issue is BitLocker, but I can't find any real evidence that anyone has got any major performance boost by disabling BitLocker. I'm also a bit reluctant to try that.

Any hints on where to proceed with this?

Improve this question
8
  • The simple solution would be to enable bitlocker on the other device and compare apples to apples.
    – Ramhound
    Feb 9, 2015 at 12:05
  • Does every project build slowly, or just 1 (review in the Output window)
    – Dave
    Feb 9, 2015 at 12:33
  • @Ramhound: Yes, that might be a simple action but will take quite some time. I'm also a bit reluctant to do that as I'm still using that machine.
    – rjnilsson
    Feb 9, 2015 at 14:27
  • @Dave: Yes, it's roughly the same difference for each of the projects. Please note that as mentioned I'm not using VS - only the command line - so I verified it by using /detailedsummary and inspecting the build times.
    – rjnilsson
    Feb 9, 2015 at 14:29
  • are you using the same version of VS and compiling the same project to compare?
    – Keltari
    Feb 9, 2015 at 16:19

1 Answer 1

Reset to default
4

I believe I've found the culprit.

The CPUs in the different exemplars are actually not that different in their capabilities:

Reported by Windows as (respectively):

  • "Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz 2.50GHz"
  • "Inter(R) Core(TM) i7-4650U CPU @ 1.70GHz 2.30GHz"

Judging from CPU speeds alone one could expect some difference in compilation speeds (disregard cache sizes, instructions sets etc for now). But then I ran Performance Monitor during builds and checked CPU usage and frequency:

When building, the CPU frequency at the Lenovo varies a bit, but averages at ~2.3GHz, while at the Surface Pro 3 it is fixed at 759MHz. Divide the two numbers and the result is close to 3 - which is what I originally observed.

I figured that there might be a possibility to force the CPU to use a higher frequency through the Power Options, but the CPU frequency range setting seems to be missing in the Surface Pro 3. There is no e.g. "High Performance" plan and even the advanced settings under a custom plan leaves the CPU-related stuff out. (And, yes, I'm measuring everything plugged in). I'll post a separate question on this specific item.

Of course, this might turn out not to be CPU-related after all, but I'll stick to that path for now.

Update:

Turning off InstantGo seems to have made the trick! It is still not possible to configure the CPU speed throttling explicitly using Power Options, but the CPU now runs at 2.3GHz when running MSBuild.

This actually results in a small (10-15%) decrease in build times on the Surface Pro vs the X220T. Perhaps the larger L3 cache or the SSD helps out here.

Note: In order to disable InstantGo I enabled Hyper-V on the Surface. There doesn't seem to be any explicit way of disabling this as I've found out.

Note 2: Disabling InstantGo does not come without a price - IIUC this means slower resumes, no activity while in standby and higher power consumption. Less of a Surface, more of a regular PC. You need to decide for yourself what your priorities are.

Update 2:

Ok, so this might be a case of stupid is as stupid does. Let me refine my findings somewhat. An important detail I failed to mention from the start was that I'm connecting to the Surface using Remote Desktop. What I currently believe now is that:

  • When I made my original tests, the Surface was already in Instant Go mode. The screen was blanked out.
  • When in that mode, the CPU seems to "lock" at 759MHz, no matter what the load is.
  • Windows 8.1 on the Surface Pro fails to recognize that there is an active user connected through RDP, and puts the system in InstantGo mode when the screen is blanked out by timer or by the user (me) pressing the power button.

So when running the "benchmark" builds without actually doing anything else than assuring that the Surface display is on, I get an even slightly faster build than the 10-15% increase seen when enabling Hyper-V on the machine - approximately another 5-10%. This is likely due to the fact that the CPU now uses Turbo Boost occasionally during the builds.

That being said, enabling Hyper-V seems to "lock" the CPU to 2.3GHz independent of the Surface's display being on or not. Not so surprising considering that the device never hits InstantGo mode in this configuration.

Improve this answer
1
  • I have exactly this use case--I use the Surface Pro 3 when traveling, and at all other times I remote into it via a desktop. Couldn't even begin to figure out why performance was so bad through Remote Desktop for what should be a decently powerful machine. Going to give this a shot.
    – bwerks
    May 15, 2015 at 3:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .