Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > hmm: code bloat?...

Reply
Thread Tools

hmm: code bloat?...

 
 
BGB / cr88192
Guest
Posts: n/a
 
      01-05-2010
hmm, an actual question of sorts...

I recently noticed in my project, which is primarily C based, a few bits of
trivia:
it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
610.5 kloc of this go into a VM project (dynamic C compiler + garbage
collector + ...).

so, ~ 1.094 Mloc of C.

about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of which
are my own code, 155 kloc coming from Quake2, errm, being essentially the
entire Q2 engine, where the code was combined mostly for my own
fiddling...).


mind that the vast majority of this is code I wrote myself, this being
primarily a single person project...


so, does something like this seem like there is a good deal of code bloat
going on?...
is it better to keep on going like this, or maybe look for parts to shave
off (even if one doesn't want to remove much?...).

or do others just keep on going as always before?...

more so, are there other implications from a codebase having a continual
tendency to inflate?... (say, if ones' code tends to inflate at an average
rate of, say, 100-150 kloc/yr or so...).



another observation:
the ratio between C and headers is notably different than in Quake2, where
Q2 has an H/C ratio of 0.14, but in my code it is closer to 0.4 or so...

any thoughts about the ration of headers and C code, or any "interesting"
implications from this property?...
(well, beyond my usage of some automatic header-writing tools, preference
for small-ish functions, ...).


....

just wondering is all...



 
Reply With Quote
 
 
 
 
bartc
Guest
Posts: n/a
 
      01-05-2010
"BGB / cr88192" <(E-Mail Removed)> wrote in message
news:hhuvlg$kg2$(E-Mail Removed)...
> hmm, an actual question of sorts...
>
> I recently noticed in my project, which is primarily C based, a few bits
> of trivia:
> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
> collector + ...).
>
> so, ~ 1.094 Mloc of C.
>
> about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of which
> are my own code, 155 kloc coming from Quake2, errm, being essentially the
> entire Q2 engine, where the code was combined mostly for my own
> fiddling...).


>
> mind that the vast majority of this is code I wrote myself, this being
> primarily a single person project...
>
>
> so, does something like this seem like there is a good deal of code bloat
> going on?...
> is it better to keep on going like this, or maybe look for parts to shave
> off (even if one doesn't want to remove much?...).


For a language project, 600kloc sounds like a lot of code to me, especially
for a one-man project.

But then, from bits of code you've posted elsewhere, you seem to like
complicated ways of doing things...

(I kept my own projects in line by doing reviews every so often and perhaps
reorganising/rewriting some subsystem or other, when it seemed about to get
out of hand, or consolidating it with another.

Revising to keep the source-code small was also quite fun to do, second only
to optimising for performance... My largest project, quite an elaborate
application, was some 150kloc; included inside that (about 20kloc) was a
bytecode compiler and interpreter...)

> or do others just keep on going as always before?...


I would say: redesign and rewrite. Otherwise I don't think you're going to
make much impact on that 1000kloc.

(However, if you're writing a commercial application, customers like value
for money. I had to ship my product on CD (this was some years ago) even
though it fitted easily on one floppy disk, to make it appear more
substantial.)

--
bartc

 
Reply With Quote
 
 
 
 
Tom St Denis
Guest
Posts: n/a
 
      01-05-2010
On Jan 5, 7:33*am, "bartc" <(E-Mail Removed)> wrote:
> For a language project, 600kloc sounds like a lot of code to me, especially
> for a one-man project.


Depends on whether you're maintaining it. I mean I write apps against
glibc, do I get to include that 100K [or whatever it is] loc in my
project tally?

If he's including the Q2 engine and only modifying a few lines here or
there to suit his particular platform he's hardly maintaining it. To
him it's just another library he links in.

His build process should really have two "clean" targets, one that
just cleans his code (removes objects corresponding to files he
maintains) and another "cleanest" [or whatever you want to call it]
that removes all objects. That wait for most of his builds he's not
rebuilding static code over and over...

Unless long build times are impressing his boss...

> (However, if you're writing a commercial application, customers like value
> for money. I had to ship my product on CD (this was some years ago) even
> though it fitted easily on one floppy disk, to make it appear more
> substantial.)


Customers for whatever reason like to think their applications are
doing a lot of thinking. That's why you'll see installers that churn
with progress bars while not really doing much of anything (I've
caught a few where the idle time was near 100% and syswait 0% and it
just sat there). Always good to put technical sounding words in there
like "optimizing data" ... [damn you Adobe...]

If you need to fill space, nothing better than 100s of 10MB files full
of random crap stuffed inside a zip archive renamed .PAK to look
important

Tom
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      01-05-2010
On 5 Jan, 09:10, "BGB / cr88192" <(E-Mail Removed)> wrote:

> hmm, an actual question of sorts...
>
> I recently noticed in my project, which is primarily C based, a few bits of
> trivia:
> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
> collector + ...).
>
> so, ~ 1.094 Mloc of C.
>
> about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of which
> are my own code, 155 kloc coming from Quake2, errm, being essentially the
> entire Q2 engine, where the code was combined mostly for my own
> fiddling...).
>
> mind that the vast majority of this is code I wrote myself, this being
> primarily a single person project...


you've written an MLOC of code...


> so, does something like this seem like there is a good deal of code bloat
> going on?...


how could we tell? Maybe you've got a MLOC of functionality in there.
I suspect with such a large code base there's *some* fat but without
looking its just a guess. What do you think? Have you tried
refactoring it?


> is it better to keep on going like this,


like what? What's wrong with what you are doing? Is it hard to modify
or debug? Is there a lot of duplicate code?

> or maybe look for parts to shave
> off (even if one doesn't want to remove much?...).


are you talking about removing duplicate code or dead code [good] or
removing little used functionality [ok] or actually reducing
functionality [sounds bad]. Do you have users? Do they want
functionality removed (in my experience- hardly ever!). Do they think
its too big?


> or do others just keep on going as always before?...


I'm a firm believer (in theory if not in practice!) that there comes a
point where things should be re-written if they get too creaky.

You should take a look at refactoring...


> more so, are there other implications from a codebase having a continual
> tendency to inflate?... (say, if ones' code tends to inflate at an average
> rate of, say, 100-150 kloc/yr or so...).


are you adding functionality? Do you refactor?


> another observation:
> the ratio between C and headers is notably different than in Quake2, where
> Q2 has an H/C ratio of 0.14, but in my code it is closer to 0.4 or so...


never measured this one. My first thought was I'd expect this be about
1.0.
A quick look at some code and... yes around 1.0. Why do you have so
few header files! And what the hell does Q2 put in its C files! Do
they use a one file per function coding standard?

> any thoughts about the ration of headers and C code, or any "interesting"
> implications from this property?...
> (well, beyond my usage of some automatic header-writing tools, preference
> for small-ish functions, ...).
>
> just wondering is all...


I tend to use a one header and c file per "module" (or class if its C+
+). Why would you have multiple C files to one header file? I suppose
a module could require multiple C files to implement it that all
communicated by one header file. Sounds like such a module needs
breaking up.

 
Reply With Quote
 
Michael Foukarakis
Guest
Posts: n/a
 
      01-05-2010
On Jan 5, 11:10*am, "BGB / cr88192" <(E-Mail Removed)> wrote:
> hmm, an actual question of sorts...


I'll try and give you an answer, sort of...

> I recently noticed in my project, which is primarily C based, a few bits of
> trivia:
> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
> collector + ...).


600 kLOC for a C VM is too much. I've actually implemented a (large)
subset of a C compiler + an interpreter + garbage collector in under
4k LOC, so I know the magnitude of the problem. Perhaps you need a lot
of code refactoring, which is expected in one man projects.

Then again, it occurs to me you might not be using the correct tools
for the job. I'd be interested to hear more details regarding your
project, actually.

> about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of which
> are my own code, 155 kloc coming from Quake2, errm, being essentially the
> entire Q2 engine, where the code was combined mostly for my own
> fiddling...).


This part sounds fairly typical.

> so, does something like this seem like there is a good deal of code bloat
> going on?...


Definitely sounds bloated (at least the first part).

> is it better to keep on going like this, or maybe look for parts to shave
> off (even if one doesn't want to remove much?...).


Definitely try to refactor. Or even redesign.

> or do others just keep on going as always before?...


Nope. I always review and reconsider my design, trying to identify
problems, limitations, etc. Perhaps not on a regular chronological
basis, but surely before the **** hits the fan - that would be when I
find out $(wc -l *.c *.h) -eq OVER NINE THOUSAND.

> more so, are there other implications from a codebase having a continual
> tendency to inflate?... (say, if ones' code tends to inflate at an average
> rate of, say, 100-150 kloc/yr or so...).


That all depends on the project really. There's no objectivity in pure
LOC.

> another observation:
> the ratio between C and headers is notably different than in Quake2, where
> Q2 has an H/C ratio of 0.14, but in my code it is closer to 0.4 or so...
> any thoughts about the ration of headers and C code, or any "interesting"
> implications from this property?


Well, such an increased ratio might mean that there's lots of macros
or functions etc. in those .h files that can be reused. Which is
somewhat contradictory to the LOC count for your project (which we
don't know what it's about, btw. Care to give a hint?).
 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      01-05-2010
"BGB / cr88192" <(E-Mail Removed)> writes:

> hmm, an actual question of sorts...
>
> I recently noticed in my project, which is primarily C based, a few bits of
> trivia:
> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
> collector + ...).
>
> so, ~ 1.094 Mloc of C.


That does seem a heck of a lot. The website in my sig is driven by
36klock of my own, and a total of 270kloc (but that includes a wiki
renderer, an HTML templating system, the SQLite database engine and a
pile of other bits).

That implements a scripting language to do the boring bits, and the
data structures to allow that scripting language to do clever things
(like compute the best path through the graph depending on current
preferences).

Four times as much seems a lot for /anything/.

I know I've a fair chunk of dead code in there as well - it still
supports legacy data formats and other databases.

> another observation:
> the ratio between C and headers is notably different than in Quake2, where
> Q2 has an H/C ratio of 0.14, but in my code it is closer to 0.4 or so...


Is that lines in *.c to lines in *.h, or number of .c files and number
of .h files?
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
BGB / cr88192
Guest
Posts: n/a
 
      01-05-2010

"Francis Glassborow" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> bartc wrote:
>> "BGB / cr88192" <(E-Mail Removed)> wrote in message
>> news:hhuvlg$kg2$(E-Mail Removed)...
>>> hmm, an actual question of sorts...
>>>
>>> I recently noticed in my project, which is primarily C based, a few bits
>>> of trivia:
>>> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
>>> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
>>> collector + ...).
>>>
>>> so, ~ 1.094 Mloc of C.
>>>
>>> about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of
>>> which
>>> are my own code, 155 kloc coming from Quake2, errm, being essentially
>>> the
>>> entire Q2 engine, where the code was combined mostly for my own
>>> fiddling...).

>>
>>>
>>> mind that the vast majority of this is code I wrote myself, this being
>>> primarily a single person project...
>>>
>>>
>>> so, does something like this seem like there is a good deal of code
>>> bloat
>>> going on?...
>>> is it better to keep on going like this, or maybe look for parts to
>>> shave
>>> off (even if one doesn't want to remove much?...).

>>
>> For a language project, 600kloc sounds like a lot of code to me,
>> especially
>> for a one-man project.
>>
>> But then, from bits of code you've posted elsewhere, you seem to like
>> complicated ways of doing things...
>>
>> (I kept my own projects in line by doing reviews every so often and
>> perhaps
>> reorganising/rewriting some subsystem or other, when it seemed about to
>> get
>> out of hand, or consolidating it with another.
>>
>> Revising to keep the source-code small was also quite fun to do, second
>> only
>> to optimising for performance... My largest project, quite an elaborate
>> application, was some 150kloc; included inside that (about 20kloc) was a
>> bytecode compiler and interpreter...)
>>
>>> or do others just keep on going as always before?...

>>
>> I would say: redesign and rewrite. Otherwise I don't think you're going
>> to
>> make much impact on that 1000kloc.

>
> I agree, it is very easy for code to grow and eventually become
> unmaintainable. I would certainly review the whole of the code base for
> starters. Though that will take some time given its size I am sure that
> you will benefit in the long run.
>


yeah.

I noted some while documenting stuff that there are things floating around
in the code that I have almost never used, for example:
the 'channels' feature I heard about from a video from Rob Pike, and then
implemented (I guess I am more used to async communication mechanisms, and
have a harder time seeing why I would have multiple threads but want them to
operate lock-step...);
some stuff for genetic-programming and neural nets, for which thus far I
have found little use (apart from specialized tools, which is where I
originally wrote this code);
....

in a few cases, I have implemented APIs which have turned out absurdly
bulky:
my class/instance system has around 500 API calls;
....

as well I guess as a general design strategy which leads to bulk:
writing an actual textual assembler, code generators which produce textual
ASM;
....

components which, in retrospect, have debatable use:
such as an x86 interpreter (this thing by itself being ~ 50 kloc);
....


> I would not worry over much about the .h/.c ratio. Well designed code
> where each function does one thing tends to have rather higher proportion
> of lines in header files but modern optimising compilers often manage to
> do link time optimisations so that your large number of functions do not
> actually result in an equivalent number of fgunction calls in the
> executable.


yeah.

I guess there is lots going on to inflate the amount of stuff present in
headers.

it is also notable that given my use of tools, pretty much all prototypes
end up in headers, rather than just ones manaually put there. Q2 seems to be
a little more lax, and only put "many" of the prototypes in headers.

I guess there are a lot of structs, ... as well, since I generally don't put
structs in C files, ...


 
Reply With Quote
 
BGB / cr88192
Guest
Posts: n/a
 
      01-05-2010

"Nick Keighley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 5 Jan, 09:10, "BGB / cr88192" <(E-Mail Removed)> wrote:
>
>> hmm, an actual question of sorts...
>>
>> I recently noticed in my project, which is primarily C based, a few bits
>> of
>> trivia:
>> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
>> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
>> collector + ...).
>>
>> so, ~ 1.094 Mloc of C.
>>
>> about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of
>> which
>> are my own code, 155 kloc coming from Quake2, errm, being essentially the
>> entire Q2 engine, where the code was combined mostly for my own
>> fiddling...).
>>
>> mind that the vast majority of this is code I wrote myself, this being
>> primarily a single person project...

>
> you've written an MLOC of code...
>


apparently...


>
>> so, does something like this seem like there is a good deal of code bloat
>> going on?...

>
> how could we tell? Maybe you've got a MLOC of functionality in there.
> I suspect with such a large code base there's *some* fat but without
> looking its just a guess. What do you think? Have you tried
> refactoring it?
>


I used to do that some, usually trying to trim down the project
occasionally.
however, I have not done that in a while, and I suspect there is a bit of a
pile-up.

the present state thus being a little over 1 Mloc of code, and around 5GB of
files (the vast majority being PNG's).


last time I did a major clean up was back when my project was in the ~ 300
kloc range, was I think a few years ago.


>
>> is it better to keep on going like this,

>
> like what? What's wrong with what you are doing? Is it hard to modify
> or debug? Is there a lot of duplicate code?
>


I meant, just keep going on coding stuff, as the codebase gets ever larger.


>> or maybe look for parts to shave
>> off (even if one doesn't want to remove much?...).

>
> are you talking about removing duplicate code or dead code [good] or
> removing little used functionality [ok] or actually reducing
> functionality [sounds bad]. Do you have users? Do they want
> functionality removed (in my experience- hardly ever!). Do they think
> its too big?
>


I could do all of these...

I suspect I may get around 50-100 kloc from dead code removal (or, more
like, dead component removal, nevermind smaller code).

removing some little-used stuff is also possible.
removing actually-used components is possible, but I guess I will probably
not do this.


>
>> or do others just keep on going as always before?...

>
> I'm a firm believer (in theory if not in practice!) that there comes a
> point where things should be re-written if they get too creaky.
>
> You should take a look at refactoring...
>


yeah, I may need to consider this.


>
>> more so, are there other implications from a codebase having a continual
>> tendency to inflate?... (say, if ones' code tends to inflate at an
>> average
>> rate of, say, 100-150 kloc/yr or so...).

>
> are you adding functionality? Do you refactor?
>


adding functionality is done a lot;
refactoring, not so much.

I had often used the "cellular" approach of splitting components if they got
too large, and interfacing components with defined APIs and allowed
dependencies. this keeps things maintainable, but does little to constrain
size (actually, abstract APIs probably make this issue worse, FWIW).


>
>> another observation:
>> the ratio between C and headers is notably different than in Quake2,
>> where
>> Q2 has an H/C ratio of 0.14, but in my code it is closer to 0.4 or so...

>
> never measured this one. My first thought was I'd expect this be about
> 1.0.
> A quick look at some code and... yes around 1.0. Why do you have so
> few header files! And what the hell does Q2 put in its C files! Do
> they use a one file per function coding standard?
>


well, I have header files for what I have them for, mostly structs and
prototypes.
I tend to use tools to mine prototypes, mostly because IMO having to go copy
prototypes to the headers is a hassle.


Q2 tends to have lots of big hairy functions (where in many cases 50-200
lines will be used by single functions), and seems to be a little lax about
which prototypes actually make it to the headers.

granted, there are a few of these in my codebase, but these tend to be a
strong minority.


well, that, and the whole engine has lots of bit twiddling and fairly nasty
use of pointer aritmetic.

or, at least by my standards where something like:
"if(*(float *)((char *)(&array_of_structs[index])+offset) == foo) ..."
is, IMO, nasty...


>> any thoughts about the ration of headers and C code, or any "interesting"
>> implications from this property?...
>> (well, beyond my usage of some automatic header-writing tools, preference
>> for small-ish functions, ...).
>>
>> just wondering is all...

>
> I tend to use a one header and c file per "module" (or class if its C+
> +). Why would you have multiple C files to one header file? I suppose
> a module could require multiple C files to implement it that all
> communicated by one header file. Sounds like such a module needs
> breaking up.
>


ok, both my project and Q2 tend to use more centralized headers with all
declarations from a "component" (where, in my terminology: component =
'library' = 'mass of code compiled into a single DLL').

basically, both my project and Q2 have the practice of creating a single
header which is included by all source files in a given library (and is
often the only header included).


but, actually, it was a measure of C loc vs H loc, FWIW...
(I have not been counting files here).

modifying line-counter to also count files, codebase totals:
1826 C files; 1795 H files.

interesting...

calculating: average C file loc is 558.4, average H file loc is 297.6.

Q2 only:
189 C files, 78 H files.
average C file loc is 821 loc, average H file loc is 278.


my codebase tends to, thus, have a much bigger portion of content in its
headers than in Q2.

IOW: my headers contain, on average, 2.86x more stuff per C kloc than Q2's C
kloc.

then again, as noted elsewhere:
tools mine prototypes, and also pretty much all structs, constant
declarations, ... go here.

but, there are lots of possible considerations here...



 
Reply With Quote
 
BGB / cr88192
Guest
Posts: n/a
 
      01-05-2010

"Michael Foukarakis" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Jan 5, 11:10 am, "BGB / cr88192" <(E-Mail Removed)> wrote:
> hmm, an actual question of sorts...


I'll try and give you an answer, sort of...

> I recently noticed in my project, which is primarily C based, a few bits
> of
> trivia:
> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
> collector + ...).


<--
600 kLOC for a C VM is too much. I've actually implemented a (large)
subset of a C compiler + an interpreter + garbage collector in under
4k LOC, so I know the magnitude of the problem. Perhaps you need a lot
of code refactoring, which is expected in one man projects.
-->

I am not sure how that is possible, assuming writing things in C...


<--
Then again, it occurs to me you might not be using the correct tools
for the job. I'd be interested to hear more details regarding your
project, actually.
-->

well, most stuff is hand-written C, but a few minor things are tool-written
(as far as C goes, this is not likely to contribute much to overall LOC).

most tasks like parsing, ... use hand-written recursive-descent parsing.

the VM project includes a number of components, and tends to compile the C
into native code which is run at runtime.

so, major components:
a garbage collector;
an assembler+linker (x86, x86-64);
a big library giving a dynamic typesystem, P-OO and C/I OO stuff, ...;
a codegen (RPNIL -> ASM, x86 / x86-64, supports: cdecl, stdcall, SysV/AMD64,
and Win64 calling conventions);
a C compiler frontend (C -> RPNIL);
a Java-ByteCode interpreter;
an x86 interpreter (simulates userspace-only, POSIX-derived process-model
and core APIs);
....


> about 483.5 kloc then is stuff related to 3D and misc (328.5 kloc of which
> are my own code, 155 kloc coming from Quake2, errm, being essentially the
> entire Q2 engine, where the code was combined mostly for my own
> fiddling...).


<--
This part sounds fairly typical.
-->

yeah.
my part also contains a 3D modeler and skeletal animation tool...


> so, does something like this seem like there is a good deal of code bloat
> going on?...


>Definitely sounds bloated (at least the first part).


> is it better to keep on going like this, or maybe look for parts to shave
> off (even if one doesn't want to remove much?...).


>Definitely try to refactor. Or even redesign.


ok.

> or do others just keep on going as always before?...


<--
Nope. I always review and reconsider my design, trying to identify
problems, limitations, etc. Perhaps not on a regular chronological
basis, but surely before the **** hits the fan - that would be when I
find out $(wc -l *.c *.h) -eq OVER NINE THOUSAND.
-->

yeah.

hmm... there was a standard tool for line-counting, and I was off having
written my own version of this as well...


> more so, are there other implications from a codebase having a continual
> tendency to inflate?... (say, if ones' code tends to inflate at an average
> rate of, say, 100-150 kloc/yr or so...).


<--
That all depends on the project really. There's no objectivity in pure
LOC.
-->

yes, ok.


> another observation:
> the ratio between C and headers is notably different than in Quake2, where
> Q2 has an H/C ratio of 0.14, but in my code it is closer to 0.4 or so...
> any thoughts about the ration of headers and C code, or any "interesting"
> implications from this property?


<--
Well, such an increased ratio might mean that there's lots of macros
or functions etc. in those .h files that can be reused. Which is
somewhat contradictory to the LOC count for your project (which we
don't know what it's about, btw. Care to give a hint?).
-->

macros, not that many...
I don't like excessive macro use.

not so many functions either, though I do make some use of "static inlines"
in a few places.

also possible is that I have some amount of functions which are
"one-liners":

void libTypeFoo(libType *obj)
{ if(obj->iface->foo) obj->iface->foo(obj); }

mostly as I really don't like code directly messing around with struct
internals if they don't actually own the struct.

....


actually, the main project is mostly 3D stuff, and random misc stuff...

it was partly merged with Q2 as part of a test, where I had noted that Q2
does lots of things my project has not mastered, and so the partial reason
for merging the codebases was to "see what happens".


otherwise, the project doesn't have a whole lot of a particular purpose,
mostly just myself and idle coding I guess...



 
Reply With Quote
 
bartc
Guest
Posts: n/a
 
      01-05-2010

"BGB / cr88192" <(E-Mail Removed)> wrote in message
news:hi05qg$jjq$(E-Mail Removed)...
>
> "Michael Foukarakis" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> On Jan 5, 11:10 am, "BGB / cr88192" <(E-Mail Removed)> wrote:
>> hmm, an actual question of sorts...

>
> I'll try and give you an answer, sort of...
>
>> I recently noticed in my project, which is primarily C based, a few bits
>> of
>> trivia:
>> it is in excess of 1Mloc (1 Mloc = 1,000,000 lines of code);
>> 610.5 kloc of this go into a VM project (dynamic C compiler + garbage
>> collector + ...).

>
> <--
> 600 kLOC for a C VM is too much. I've actually implemented a (large)
> subset of a C compiler + an interpreter + garbage collector in under
> 4k LOC, so I know the magnitude of the problem. Perhaps you need a lot
> of code refactoring, which is expected in one man projects.
> -->
>
> I am not sure how that is possible, assuming writing things in C...


That does sound tight. I would have reckoned on several 10Kloc of
C/C-equivalent code for such a project. Perhaps he missed out a zero.

> the VM project includes a number of components, and tends to compile the C
> into native code which is run at runtime.
>
> so, major components:
> a garbage collector;
> an assembler+linker (x86, x86-64);
> a big library giving a dynamic typesystem, P-OO and C/I OO stuff, ...;
> a codegen (RPNIL -> ASM, x86 / x86-64, supports: cdecl, stdcall,
> SysV/AMD64, and Win64 calling conventions);
> a C compiler frontend (C -> RPNIL);
> a Java-ByteCode interpreter;
> an x86 interpreter (simulates userspace-only, POSIX-derived process-model
> and core APIs);
> ...


This doesn't sound like a single executable. So perhaps you shouldn't just
combine all the Loc for each.

--
Bartc

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
what is the difference between code inside a <script> tag and code in the code-behind file? keithb ASP .Net 1 03-29-2006 01:00 AM
Fire Code behind code AND Javascript code associated to a Button Click Event =?Utf-8?B?Q2FybG8gTWFyY2hlc29uaQ==?= ASP .Net 4 02-11-2004 07:31 AM
Re: Code Behind vs. no code behind: error Ben Miller [msft] ASP .Net 1 06-28-2003 01:46 AM
Re: C# Equivalent of VB.Net Code -- One line of code, simple Ian ASP .Net 0 06-25-2003 01:14 PM
Re: C# Equivalent of VB.Net Code -- One line of code, simple Ron ASP .Net 1 06-24-2003 07:18 PM



Advertisments