[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: following up on speed
[Much good stuff about GC deleted].
>OTOH the lack of GC discourages C
>programmers from using anything other than trivial data structures; I'd
>argue that this is a huge cost in terms of code complexity which dwarfs the
>efficiency costs of GC.
Gee. Are we biased or what? In my experience when systems (with GC)
get large enough (I'm not talking about academic programs here)
Lisp/Scheme/Java programmers do spend a great deal of time looking at
how allocation works/impacts their programs -- almost on par w/ how
much time a C programmer might spend initially tuning allocations and
perhaps later in debugging malloc/free issues perhaps. And indeed I've
seen the exact opposite of what Michael is talking about -- most
complex code I've seen wrt. data structures is still C and god forbid
Fortran. This might mean more about what Math and Physics majors are
taught than anything intrinsic about languages per se :)
It might be interesting to see "time spent on memory allocation
issues" through the life cycle of a project. I doubt it's as clear as
some of you seem to be talking about.
Finally, when you are staring at 50 meg executables and 200Meg VM
startup time / paging issues, it has been my experience that it is
much harder to fine tune a system w/ GC -- linked lists etc. are
great, but think about what happens when you have a few millions of
them spread around a few hundred critical object/datastructures. One
can't always be rapid prototyping around production issues.