4 ms·

Great! Can you prove it? There's a benchmark: http://www.techempower.com/benchmarks/#section=data-r6&hw=winec2&test=db http://www.techempower.com/benchmarks/#

by CCs 13y ago

Great! Can you prove it? There's a benchmark: http://www.techempower.com/benchmarks/#section=data-r6&hw=winec2&test=db http://www.techempower.com/benchmarks/#section=data-r6&hw=wi... Go-lang is roughly 10 times faster than ASP.NET (implemented as recommended by Microsoft). Skipping the ORM doubles the speed, but then you lose most of the components, so I'm not sure that's a realistic optimization. Can you do better?

MalcolmEvershed 13y ago
In case anyone is curious what is going on with those ASP.NET TechEmpower benchmarks: The TechEmpower benchmarks are all about how much overhead you can eliminate. I profiled the CPU-bound ASP.NET TechEmpower benchmarks and most of the time is spent in IIS<->ASP.NET overhead. After I removed IIS and ASP.NET by just using the .NET HttpListener class [0], the result (on my machine) gives Go a run for its money. Hopefully these results will show up in the next Round that TechEmpower runs. I profiled the .NET TechEmpower tests that access PostgreSQL and MySQL and found that the database drivers had a lot of unnecessary overhead, for example the Oracle .NET MySQL provider does a synchronous ping to the MySQL Server for every connection, even if it's pooled. Plus, it sends an extra 'use database;' command. [1] The PostgreSQL provider also sends extra synchronous commands for every connection. [2] [0] https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/HttpListener https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast... [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/315 https://github.com/TechEmpower/FrameworkBenchmarks/issues/31... [2] https://github.com/TechEmpower/FrameworkBenchmarks/pull/325#commitcomment-3373154 https://github.com/TechEmpower/FrameworkBenchmarks/pull/325#...
- CCs 13y ago
  So C++ is bad because certain functions should be avoided and has no garbage collector. (With C++11 STL normally there's no need for manual memory management or naked pointers.) C# is good, just you should avoid the garbage collector and 90% of the standard library. Roll your own web server, raw sql commands, have manual memory management, use undocumented calls, emit byte code and there you have: almost 40% of the C++ performance. I'm the only one who thinks this does not make any sense?
  - bcoates 13y ago
    I don't understand how you got there from the parent post. The github links look like idiomatic C# to me, aside from avoiding IIS. IIS has nothing to do with C# vs C++ vs anything else.
  - MalcolmEvershed 13y ago
    No, I'm not implying any of that. I'm just saying that an important step to getting good performance is profiling to determine the cause of poor performance, then deciding whether it makes sense to try to improve performance in the found areas, then executing your decision. Imagine the alternative if I didn't profile: I'd just declare that C++/whatever is way faster than ASP.NET, and I'd switch to C++ and open myself to a whole world of debugging memory corruption issues whatnot. Instead, because I profiled, I found the areas that could be improved, I wrote the HttpListener code and I can stay on the .NET platform for all of its other benefits. By following this process I have more options than just "C# blows, I gotta throw it out the window for C++". In reality, I have probably written more useful, shipped, production C/C++ than C#, so I'm also a C++ advocate, but hey, when it makes sense, and for the right reasons, you know?
barrkel 13y ago
Can you prove it? Can I do what exactly? I'm not your monkey. The application we built did not access the database per request. That was the point of the blob of data that was not serialized and deserialized; it was a disconnected data set. IIS was used purely as a driver for an IHttpHandler implementation. We didn't use any of ASP.NET apart from implement that interface. We implemented our own AJAX component system before ASP.NET had AJAX controls. It was fairly quick on 2003 hardware. Further, the blob of data started out with an embedded URL that referenced a private metadata server, with the version of the app included in the URL. The behaviour for the objects in the little heap was driven from code loaded (normally, cached) via that URL. This meant that you could post-mortem a session by loading up the heap almost like you load up a core dump; you could save the heap along with the request if an error occurred, and have everything you needed for a full repro. The fact that the URL referenced the code for the behaviour also meant we could roll out updates without ever restarting anything, and existing sessions would see the old behaviour until they were finished, but new sessions would roll over immediately to the new code. For the niche (data entry, specifically for the insurance industry), I have yet to see a better system than the one we built; it was declarative and typed, and if it compiled, you could be pretty sure it worked, and yet had a built-in API for testing. Loading up the aforementioned core dump even had a REPL. Rails is an enormous pile of work and rats nest of polyglot spaghetti by comparison. To take a specific example, the application code had a definition for the UI for any given page, and knew what controls were on it, and knew their master / detail relationships. The controls had bindings that were evaluated in the context of the object model stored in the little heap, written in a little expression language called Gravity (so called because it sucked in other responsibilities). So when the end-user loaded up a page, the declaration of the UI and its bindings were sufficient to infer what data to send down to the client; and when e.g. a button was clicked, and the model changed, we could calculate minimal updates to send back to the client. Because the framework knew so much about the app declaratively, you had to do very little work to implement things.

by CCs 13y ago

MalcolmEvershed 13y ago

In case anyone is curious what is going on with those ASP.NET TechEmpower benchmarks: The TechEmpower benchmarks are all about how much overhead you can eliminate. I profiled the CPU-bound ASP.NET TechEmpower benchmarks and most of the time is spent in IIS<->ASP.NET overhead. After I removed IIS and ASP.NET by just using the .NET HttpListener class [0], the result (on my machine) gives Go a run for its money. Hopefully these results will show up in the next Round that TechEmpower runs. I profiled the .NET TechEmpower tests that access PostgreSQL and MySQL and found that the database drivers had a lot of unnecessary overhead, for example the Oracle .NET MySQL provider does a synchronous ping to the MySQL Server for every connection, even if it's pooled. Plus, it sends an extra 'use database;' command. [1] The PostgreSQL provider also sends extra synchronous commands for every connection. [2] [0] https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/HttpListener https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast... [1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/315 https://github.com/TechEmpower/FrameworkBenchmarks/issues/31... [2] https://github.com/TechEmpower/FrameworkBenchmarks/pull/325#commitcomment-3373154 https://github.com/TechEmpower/FrameworkBenchmarks/pull/325#...

CCs 13y ago
So C++ is bad because certain functions should be avoided and has no garbage collector. (With C++11 STL normally there's no need for manual memory management or naked pointers.) C# is good, just you should avoid the garbage collector and 90% of the standard library. Roll your own web server, raw sql commands, have manual memory management, use undocumented calls, emit byte code and there you have: almost 40% of the C++ performance. I'm the only one who thinks this does not make any sense?
- bcoates 13y ago
  I don't understand how you got there from the parent post. The github links look like idiomatic C# to me, aside from avoiding IIS. IIS has nothing to do with C# vs C++ vs anything else.
- MalcolmEvershed 13y ago
  No, I'm not implying any of that. I'm just saying that an important step to getting good performance is profiling to determine the cause of poor performance, then deciding whether it makes sense to try to improve performance in the found areas, then executing your decision. Imagine the alternative if I didn't profile: I'd just declare that C++/whatever is way faster than ASP.NET, and I'd switch to C++ and open myself to a whole world of debugging memory corruption issues whatnot. Instead, because I profiled, I found the areas that could be improved, I wrote the HttpListener code and I can stay on the .NET platform for all of its other benefits. By following this process I have more options than just "C# blows, I gotta throw it out the window for C++". In reality, I have probably written more useful, shipped, production C/C++ than C#, so I'm also a C++ advocate, but hey, when it makes sense, and for the right reasons, you know?

barrkel 13y ago

Can you prove it? Can I do what exactly? I'm not your monkey. The application we built did not access the database per request. That was the point of the blob of data that was not serialized and deserialized; it was a disconnected data set. IIS was used purely as a driver for an IHttpHandler implementation. We didn't use any of ASP.NET apart from implement that interface. We implemented our own AJAX component system before ASP.NET had AJAX controls. It was fairly quick on 2003 hardware. Further, the blob of data started out with an embedded URL that referenced a private metadata server, with the version of the app included in the URL. The behaviour for the objects in the little heap was driven from code loaded (normally, cached) via that URL. This meant that you could post-mortem a session by loading up the heap almost like you load up a core dump; you could save the heap along with the request if an error occurred, and have everything you needed for a full repro. The fact that the URL referenced the code for the behaviour also meant we could roll out updates without ever restarting anything, and existing sessions would see the old behaviour until they were finished, but new sessions would roll over immediately to the new code. For the niche (data entry, specifically for the insurance industry), I have yet to see a better system than the one we built; it was declarative and typed, and if it compiled, you could be pretty sure it worked, and yet had a built-in API for testing. Loading up the aforementioned core dump even had a REPL. Rails is an enormous pile of work and rats nest of polyglot spaghetti by comparison. To take a specific example, the application code had a definition for the UI for any given page, and knew what controls were on it, and knew their master / detail relationships. The controls had bindings that were evaluated in the context of the object model stored in the little heap, written in a little expression language called Gravity (so called because it sucked in other responsibilities). So when the end-user loaded up a page, the declaration of the UI and its bindings were sufficient to infer what data to send down to the client; and when e.g. a button was clicked, and the model changed, we could calculate minimal updates to send back to the client. Because the framework knew so much about the app declaratively, you had to do very little work to implement things.