You use linq where it makes sense, generally where accuracy/correctness is important and performance is a tertiary concern. Dotnet code that deals with reading text streams are generally high optimization scenarios, where linq is scrubbed in favor of performance to eliminate the enumerable overhead. You won’t find code like that in serializers, for example. The only other example I can think of would be reading a file on intialization, which wouldn’t use this approach and would run once or rarely.

While I fully believe you’ve seen this impl somewhere, it’s not any standard professional library approach I’ve seen over the past 20+ years in any library remotely concerned with performance.

Agree, LINQ is slow. I use it when speed isn’t an issue, but if my code is processing lots of data and slow, one of the first things I’m going to do is remove LINQ and see if that speeds it up.

I dunno. I just don’t consider synchronous unbuffered byte-by-byte file read a “real world scenario” – at least not in 99.99% cases. But that’s just me I guess.

Well, I feel that part of the reason you choose a language is productivity and performance, probably among other thins. As it turns-out, that’s also how I think, I also greatly value the maintainability. I could go work on a C# project for months, and pick-up a Go project and just feel right at home in less than an hour, and that’s very difficult in C#.

There has been a time where I was having a good long and hard thoughts of comparisons between C# and Go. In the end, Go has won my heart, mainly because of its simplicity mixed with decent performance and productivity. There’s also the power to go down deep to assembly (right within Go, the integration is just so straightforward) for extreme performance, or fly as high to your heart’s content while still being surprisingly fast even with the first attempt (like the above codes).
At first glance, Go seems kinda of verbose, similar to C/C++/C#, however, once you get used to it, it just feels natural and it just flows like how you speak words, may be because of its simplicity.

Lack of generics have been the negative point for Go (but I used Go for 9 years or so without finding it a real bottleneck), but this month, the v1.18 will come out and will have generics baked-in (been cooking for a very long time). So, the coming month of April, I believe a lot of blog posts will talk about this very welcomed generics feature, and you could jump on then.

I can’t really tell you how good programming in Go is, but for the values you’re seeking for, I believe you’ll be greatly satisfied with Go, like I was, especially now with generics. Docker, Kubernetes, Podman, etc… are all made possible thanks to Go. I believe there are some blogs about the decision to use Go for these projects.

Anyway, it would be interesting to see comparisons of how fast other programming languages are when doing real world tasks like what you had in this blog, including the counting of ‘1’ not just file read, given that you already do Scala and Python in addition to PHP.

Yes, if people basically want to point out buffering as being an issue, despite me saying that yes, the C# version is doing the same thing, in the article itself. I will tell people to read the article. If you want to erroneously point out that optimizations are turned off, without reading the sentence where they say they are turned on or checking the Dockerfiles to see what is actually being done, I will tell you to read the article.

If you point out how the code can be improved, the code will be improved. As I’ve mentioned several times though, I saw this issue (among with others) in real life code when porting microservices to C# from PHP. C# is slower than PHP in some real world cases, which is surprising (even to me)! Can we make C# actually faster than PHP? Maybe, maybe not, but it doesn’t help when the code lives deep in libraries in the real world.

Well, I say, give Go a go 🙂

Go is very much on my list of languages to learn well. There are quite a few amazing libraries that I’ve wanted to use directly instead of a shim around a CLI for some personal projects. I’d love for an excuse to use it at work (Python/Scala/PHP are the languages I use at work), and we do have some tooling written in Go that could probably use a fresh set of eyes… anyway, you make a really good point about PHP being built on C vs. pure C#. I wonder if that is why it is also slower with some types of collections, and database accessing? I really appreciate your comments btw!

Google Sign-in for your comments system doesn’t seem to work

Good to know and thanks for reporting it! A lot of this blog is almost 10 years old at this point, it might be time to reinstall everything from scratch!

I read your article alright, including the original post. But as you can notice, my post was not really around the file read but the actual C# code being compared to a PHP: C# was almost fully user-land whereas the PHP was barely. I agree that for some reasons, plain file read is indeed apparently faster on PHP, but like I said, I’m no C# expert and I believe it falls-down to the choice of API that one uses in this one single case of file read comparison. That could also depend on the runtime, Mono and dotnet would probably incur differences, I didn’t seem to have found any mention of the runtime infos.

For the choice of language, I’m not a fan of PHP, obviously (14 years ago, I was a fan of PHP). I don’t see any real benefits moving from C# to PHP, C# has a much wider application opportunities and ecosystem, and it has a massive experience re-use. That can’t be said with PHP.

Anyway, you said in your original post: “If you haven’t used PHP in the last 7-8 years, you should give it a go”. Well, I say, give Go a go 🙂

By the way, the Google Sign-in for your comments system doesn’t seem to work. So I opted for the Facebook ID.