6 ms·
Great, but unfortunately, even when compiled, the startup overhead is about half a second, which makes it unsuitable for many applications. Still I applaud it,
by jbverschoor 1y ago
Great, but unfortunately, even when compiled, the startup overhead is about half a second, which makes it unsuitable for many applications. Still I applaud it, as Shell scripting is finicky, people thend to rely on bash features, and perl is kind of over. Ruby was, and still is, my go-to language for this purpose, but I've recently migrated some scripts over to Swift.
Swift does a much better job at this as interprets by default, and a compiled version starts instantaneously. I made a transparent caching layer for your Swift cli apps.Result: instant native tools in one of the best languages out there.
Swift Script Caching Compiler (https://github.com/jrz/tools https://github.com/jrz/tools)
dotnet run doesn't need it, as it already caches the compiled version (you can disable with --no-build or inspect the binaries with --artifacts-path)
- alkonaut 1y agoDoes this recompile each time? It should be simple to cache the binary on the hash of the input? A sub second first run followed by instant rerun seems acceptable.
- wiso 1y agoBinaries are cached and next runs are much faster
- jbverschoor 1y agoThe dotnet run command caches. However, even with the cached version, you have a startup overhead of about half a second on my M1. My "Swift Script Caching Compiler" compiles and caches, but will stay in interpreted mode the first three runs when you're in an interactive terminal. This allows for a faster dev-run cycle.
- motorest 1y ago> Great, but unfortunately, even when compiled, the startup overhead is about half a second, which makes it unsuitable for many applications. Which applications are those? I mean, one example they showcase is launching a basic web service.
- jbverschoor 1y agoI’d say anything except long running processes or scripts that take 5+ second to complete. Cli scripts/apps should simply be responsive, just like websites and apps shouldn’t be slow to open. Slower scripts result in distraction, which ultimately leads to hackernews being in front of your nose again. A few of my examples: Resizing/positioning windows using shortcut keys. Unbearable if it’s not instantaneous. Open a terminal based on some criteria. Annoying if I have to wait.
- motorest 1y ago> I’d say anything except long running processes or scripts that take 5+ second to complete. I don't think you're presenting a valid scenario. I mean, the dotnet run file.cs workflow is suited for one-off runs, but even if you're somehow assuming that these hypothetical cold start times are impossible to optimize (big, unrealistic if) then it seems you're missing the fact that this feature also allows you to build the app and generate a stand-alone binary. So exactly what's the problem?
- jbverschoor 1y agoBut it doesn’t. It still seems to run in JIT mode, instead of AOT. That’s exactly why I made swift-scc (interpret vs compile, but essentially the same problem)
- motorest 1y ago> But it doesn’t. I recommend you read the article. They explicitly address the usecases of "When your file-based app grows in complexity, or you simply want the extra capabilities afforded in project-based apps".
- jbverschoor 1y agoComplexity is not the problem. It a simple hello world example. Imagine cat, ls, cd, grep, mkdir, etc. would all take 500ms. It’s the same as the electron shit. It’s simply not necessary
- Kuinox 1y agoWhere does your half a second number come from ? I ran a hello world to test, the overhead is 63ms. neuecc ran benchmark on CLI libs overhead, none reach half a second: https://neuecc.medium.com/consoleappframework-v5-zero-overhead-native-aot-compatible-cli-framework-for-c-8f496df8d9d1 https://neuecc.medium.com/consoleappframework-v5-zero-overhe... > Swift does a much better job at this as interprets by default The .NET JIT is a tiered JIT, it doesn't immediatly emit code immediatly.
- bouke 1y agoNot GP, but can confirm on my M3 Max using the hello world sample: $ time dotnet run hello-world.cs > /dev/null real 0m1.161s user 0m0.849s sys 0m0.122s $ time dotnet run hello-world.cs > /dev/null real 0m0.465s user 0m0.401s sys 0m0.065s
- masfuerte 1y agoThis is nuts. More than a decade ago Microsoft made a big deal of startup optimisations they had made in the .Net framework. I had some Windows command-line apps written in C# that always took at least 0.5s to run. It was an annoying distraction. After Microsoft's improvements the same code was running in 0.2s. Still perceptible, but a great improvement. This was on a cheap laptop bought in 2009. I'm aware that .Net is using a different runtime now, but I'm amazed that it so slow on a high-end modern laptop.
- thatnerdyguy 1y agoTo be fair, this is timing early bits of a preview feature. Compiled .NET apps have much better startup perf.
- toyg 1y agoThey are not on Windows. As someone else pointed out, there are very likely Apple-specific shenanigans going on.
- doomroot13 1y ago
- davidgl 1y agoIf you want it to start up quickly, you can easily covert it to native code using https://learn.microsoft.com/en-us/dotnet/core/deploying/ https://learn.microsoft.com/en-us/dotnet/core/deploying/
- bencyoung 1y agoDotnet is getting a fully interpreted mode in 10 or 11 so I wonder if they'll switch to that for things like this https://github.com/dotnet/runtime/issues/112748 https://github.com/dotnet/runtime/issues/112748
- nobodyandproud 1y agoPython seems to fit the old Perl niche.
- rprouse 1y agoThis is still in early preview. They acknowledged the startup speed in several presentations I saw and said that they are working on speeding it up.
- opendomain 1y agoIt may be that they are speeding it up by keeping the .net runtime resident in memory. They used to do this with Visual Basic runtime I ran norton utilities on my pc yesterday and noticed a new service - it was .net runtime. Please note that I am a developer so this may be just to help launch the tools.
- smileybarry 1y agoThat’s probably just a non-Visual Studio version of what VS already does with reusing .NET-hosting processes when you run an app in debug mode.
- high_na_euv 1y ago>Great, but unfortunately, even when compiled, the startup overhead is about half a second, which makes it unsuitable for many applications So why python is this popular in this domain?
- jbverschoor 1y agoPython has replaced Java in many universities, and is used in other domains than CS. Python caches compiled versions by default. (__pycache__) and simply starts faster. Python is more a scripting language, similar to Ruby. Swift was late to the game, and is quite strict. *performance is a feature* And in particular perceived performance and startup performance (“lag”) It’s one of the reasons for the success of Chrome, MySQL, Mongodb, and many others.
- ptx 1y agoA Python script can start and finish in less than 10 ms on my machine.
- high_na_euv 1y agoEven with installing dependencies? Because that's what dotnet run does
- ptx 1y agoDoes dotnet install the script's dependencies all over again every time you run it? The quoted part was about the 0.5 second startup overhead, which I figured did not include installing the dependencies. Anyway, lots of Python scripting can be done with the standard library, without installing any dependencies. I rarely use third-party dependencies in my Python scripts.
- high_na_euv 1y ago1. I don't think so, but it may check it if is needed? I don't know. 2. Same can be said about C# which has really strong and well designed (APIs) standard lib.
- Koshkin 1y agoI use “tcc -run” instead. It’s instantaneous.
- merb 1y agoRuby can be slow as hell as well. Start the ruby shell for gitlab. Of course this only happens when tons of packages are loaded which will probably never happen for a cli tool, right?
- edu_guitar 1y agoHave you heard of crystal[0]? It is very close to ruby, but compiled, with fast start times. [0]: https://crystal-lang.org/ https://crystal-lang.org/