LinqPad 6 First Execution Slow, Then Blazing Fast

mldisibio

I did some searching but did not find any previous discussion. Recently v6.9.15 x64 I've noticed dramatic time differences between first and subsequent execution of C# programs that do large amounts of I/O.

Let's say I perform a word search intersecting each of 10,000 large text files with an array of words (example only). No exotic NuGet packages. Just System.IO, System.Linq, etc

The first run will be noticeably slow, sometimes on the order of minutes. Second run will be ludicrously fast, order of single seconds (almost feels like all the results and text content were cached, and yet if the text files change, the results are live and correct).
I am sure there is some .net core caching or pre-compiling or optimization going on.

1) Can someone offer a brief explanation of what pre-compile work LinqPad is doing the first run?
2) Any configuration options to tinker with first response time? I remember in LinqPad 5 one could toggle 'shadow assembly references' in which references were copied to a temp folder, but I don't see that option for v6 anymore.

Thanks in advance.

JoeAlbahari

With subsequent executions, LINQPad uses the same process and so anything that's cached in memory by your script will benefit in performance. This hasn't changed in any recent LINQPad update.

A simple script in LINQPad takes maybe tens of milliseconds to compile, so that shouldn't be the issue. And NuGet references are not normally copied anywhere - LINQPad loads them directly from the machine cache.

Have you tried the same thing on another machine?

Something else to keep in mind is that the operating system also caches recently accessed data on the hard drive, so that will affect performance, too.

mldisibio

Thanks Joe. It wasn't so much a complaint as much as trying to understand such a radical execution difference that looks like black magic. As a LinqPad user for years I've noticed a slight performance gain in the subsequent executions over the first, but nothing this dramatic.

tldr: Might also be due to updated virus scanner and corporate group policy updates. No worries.

But now that I think about it, when I first started at my most recent company about a year ago (still using LPv5) they issued workstations where we did not have admin rights. LinqPad would lag horribly on first execution for even the simplest of tasks, which it never did in any other environment for the previous decade. My thought process was: 1) LinqPad compiles/writes an executable. 2) Corporate Virus Scanner and UAC kicks in 3) If nothing changes, subsequent executions are not bothered by the Virus Scanner or UAC

Then I got admin rights, updated .Net Core, updated Visual Studio, updated LinqPad, etc etc and that behavior went away, or so it seemed, so I happily forgot about it.

But, in fact, this latest dramatic behavior is particularly noticeable with I/O, AND I just got a new external drive...and so now I'm thinking Virus Scanner plus BitLocker are slowing down the first execution/compilation. Actually, to be honest, I think with all the Covid WFH for the past six months, corporate software and policy updates were not being pushed over VPN correctly until very recently and suddenly the Virus Scanner and maybe some other policy has recently awoken with renewed vengance.

As always, Thank you for LinqPad.