7 ms·

Well... there is at least some sense in writing a webapp in C. If you rely on operating system primitives for security (processes, Unix filesystem permissions,

by catern 10y ago

Well... there is at least some sense in writing a webapp in C. If you rely on operating system primitives for security (processes, Unix filesystem permissions, seccomp/pledge/capsicum) instead of language features (bounds checking, garbage collection, etc.) then just maybe you could get performance gains while still being secure. But in reality writing applications in a hosted environment/virtual machine is more performant than writing it in C and locking it down with operating system features. And of course more secure. The author's efforts would be better spent on improving the performance of OS-based security (processes, filesystems), than attempting to use that security as it stands. There are all kinds of tricks that could be implemented to improve things...

aidenn0 10y ago
If you are using CGI, then you probably already don't care about performance. On top of that, the CPU throughput overhead of using a compiled managed language is typically less than a factor of 2, which, combined with the fact that the majority of web applications are not compute bound means the number of webapps that it would make any sense to write in C is nearly zero. Pretty much all pithy advice (such as "Don't write your webapps in C") has an implicit exception "Unless you fully understand why I made this recommendation and have good reasons for why they don't apply." That exception is not made explicit because 1) It would make the advice less pithy and 2) Then those who would most benefit from the advice convince themselves that it doesn't apply to them.
- SwellJoe 10y ago
  "If you are using CGI, then you probably already don't care about performance." So...I think you're missing a few pieces of the puzzle with this statement. The statement is a truism that is right almost always, but it has exceptions, and this is one of those exceptions. CGI is slow when startup time for your app is slow, because of a VM, because of the library loading overhead, because of environment setup, because of some thing that isn't really the fault of CGI per se. CGI can be fast, or at least fast enough, if startup time for your app is very fast. An app written in C, statically linked, could potentially start and respond faster than many dynamic language apps could even when running in an app server. C is fast. C is small. C is also particularly error-prone, would be a little verbose for web apps, and does not have a good ecosystem of support libraries for web apps, but even if running it without an app server in a CGI mode it could be fast enough for most deployments. The CGI interface is not why CGI apps are slow. CGI apps are slow because startup of many modern language environments is slow. C is a language that doesn't have to be slow in that context. (Though, it could be faster still by using an FCGI or other app server model and having your C web app running all the time, so it just has to answer requests over a socket or whatever...though async programming in C is also hard to get right for inexperienced programmers.)
  - qwertyuiop924 10y ago
    Huh. I wonder what the start time is on the language I'm using for CGI work. (I'm using CHICKEN, which is a compiled Scheme R5RS implementation with numerous extensions).
    - SwellJoe 10y ago
      Probably fine for some things, since it is compiled, and, as I understand it is pretty fast. I don't know a lot about the internals of chicken, but since it's a Scheme wouldn't it need some kind of VM for macros and memory management and such? That'd impose some kind of startup overhead that C wouldn't have. But, then again, Perl can start fast enough for some things (though most Perl web app developers use some sort of app server, because they rely on a bunch of libraries that would increase startup time remarkably if it had to happen for every request). Do you write command line apps with CHICKEN? Are they super fast to start, like instant (comparable to something written in C or small Perl scripts)? If so, then CGI could probably be fast enough for some use cases. If you can perceive the startup time, then no, it'd be kinda sucky when used with CGI.
      - qwertyuiop924 10y ago
        >wouldn't it need some kind of VM for macros and memory management and such? Not a VM: it's compiled. It needs to bind to libchicken, and it needs to do some things that native C programs wouldn't. Also, you wouldn't need a VM for macros: they're a compile-time feature, and don't even exist at runtime. Yeah, it's not humanly noticable.
      - aidenn0 10y ago
        For what it's worth, SBCL (which essentially in all ways completely unrelated to chicken other than them both being native compiled dynamic languages) can startup a minimal runtime and exit in 3.8ms on my system. it goes up to about 5ms for a moderate sized application (which includes some dynamically linked libraries that must be loaded). on the same system: /bin/true starts up in 0.5ms /usr/bin/env perl starts up in 2.4ms /usr/bin/perl starts up in 1.8ms If you want to run your own benchmarks, just use time and something like this small program (I ran with 1000 iterations): #include <sys/types.h> #include <sys/wait.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char *argv[]) { int i; int iter=atoi(argv[1]); for(i=0;i<iter;++i) { pid_t pid=fork(); if(pid) { waitpid(pid,NULL,0); } else { execl(argv[2],argv[2],NULL); } } return 0; }
- ec109685 10y ago
  All web apps are CPU bound. At a certain point, your backend is done and it's up to the web app to compute a return value (similarly for the part that calculates the backend request). That part of the request is cpu bound.
moosingin3space 10y ago
> just maybe you could get performance gains Not too sure about that -- Erlang/OTP-based web applications have very good performance (and transparent scaling) with a fraction of the code of a hand-rolled C-based web application. I honestly think web applications are a place where everything but assembly is better than C.

by catern 10y ago

aidenn0 10y ago

If you are using CGI, then you probably already don't care about performance. On top of that, the CPU throughput overhead of using a compiled managed language is typically less than a factor of 2, which, combined with the fact that the majority of web applications are not compute bound means the number of webapps that it would make any sense to write in C is nearly zero. Pretty much all pithy advice (such as "Don't write your webapps in C") has an implicit exception "Unless you fully understand why I made this recommendation and have good reasons for why they don't apply." That exception is not made explicit because 1) It would make the advice less pithy and 2) Then those who would most benefit from the advice convince themselves that it doesn't apply to them.

SwellJoe 10y ago
"If you are using CGI, then you probably already don't care about performance." So...I think you're missing a few pieces of the puzzle with this statement. The statement is a truism that is right almost always, but it has exceptions, and this is one of those exceptions. CGI is slow when startup time for your app is slow, because of a VM, because of the library loading overhead, because of environment setup, because of some thing that isn't really the fault of CGI per se. CGI can be fast, or at least fast enough, if startup time for your app is very fast. An app written in C, statically linked, could potentially start and respond faster than many dynamic language apps could even when running in an app server. C is fast. C is small. C is also particularly error-prone, would be a little verbose for web apps, and does not have a good ecosystem of support libraries for web apps, but even if running it without an app server in a CGI mode it could be fast enough for most deployments. The CGI interface is not why CGI apps are slow. CGI apps are slow because startup of many modern language environments is slow. C is a language that doesn't have to be slow in that context. (Though, it could be faster still by using an FCGI or other app server model and having your C web app running all the time, so it just has to answer requests over a socket or whatever...though async programming in C is also hard to get right for inexperienced programmers.)
- qwertyuiop924 10y ago
  Huh. I wonder what the start time is on the language I'm using for CGI work. (I'm using CHICKEN, which is a compiled Scheme R5RS implementation with numerous extensions).
  - SwellJoe 10y ago
    Probably fine for some things, since it is compiled, and, as I understand it is pretty fast. I don't know a lot about the internals of chicken, but since it's a Scheme wouldn't it need some kind of VM for macros and memory management and such? That'd impose some kind of startup overhead that C wouldn't have. But, then again, Perl can start fast enough for some things (though most Perl web app developers use some sort of app server, because they rely on a bunch of libraries that would increase startup time remarkably if it had to happen for every request). Do you write command line apps with CHICKEN? Are they super fast to start, like instant (comparable to something written in C or small Perl scripts)? If so, then CGI could probably be fast enough for some use cases. If you can perceive the startup time, then no, it'd be kinda sucky when used with CGI.
    - qwertyuiop924 10y ago
      >wouldn't it need some kind of VM for macros and memory management and such? Not a VM: it's compiled. It needs to bind to libchicken, and it needs to do some things that native C programs wouldn't. Also, you wouldn't need a VM for macros: they're a compile-time feature, and don't even exist at runtime. Yeah, it's not humanly noticable.
    - aidenn0 10y ago
      For what it's worth, SBCL (which essentially in all ways completely unrelated to chicken other than them both being native compiled dynamic languages) can startup a minimal runtime and exit in 3.8ms on my system. it goes up to about 5ms for a moderate sized application (which includes some dynamically linked libraries that must be loaded). on the same system: /bin/true starts up in 0.5ms /usr/bin/env perl starts up in 2.4ms /usr/bin/perl starts up in 1.8ms If you want to run your own benchmarks, just use time and something like this small program (I ran with 1000 iterations): #include <sys/types.h> #include <sys/wait.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char *argv[]) { int i; int iter=atoi(argv[1]); for(i=0;i<iter;++i) { pid_t pid=fork(); if(pid) { waitpid(pid,NULL,0); } else { execl(argv[2],argv[2],NULL); } } return 0; }
ec109685 10y ago
All web apps are CPU bound. At a certain point, your backend is done and it's up to the web app to compute a return value (similarly for the part that calculates the backend request). That part of the request is cpu bound.

moosingin3space 10y ago

> just maybe you could get performance gains Not too sure about that -- Erlang/OTP-based web applications have very good performance (and transparent scaling) with a fraction of the code of a hand-rolled C-based web application. I honestly think web applications are a place where everything but assembly is better than C.