Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #112461 > unrolled thread

[BBC] Programmers who use spaces 'paid more'

Back to article view | Back to comp.lang.c

Contents

  [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-18 21:45 +0800
    Re: [BBC] Programmers who use spaces 'paid more' Per Sandberg <per.s.sandberg@bahnhof.se> - 2017-06-18 22:13 +0200
      Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 19:03 -0400
        Re: [BBC] Programmers who use spaces 'paid more' Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 20:22 -0400
        Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-19 07:50 +0200
          Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 22:28 +0800
        Re: [BBC] Programmers who use spaces 'paid more' gordonb.nakyl@burditt.org (Gordon Burditt) - 2017-06-19 03:24 -0500
          Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-19 18:42 +0200
        Re: [BBC] Programmers who use spaces 'paid more' Snit <usenet@gallopinginsanity.com> - 2017-06-19 20:00 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 18:46 +0800
    Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-18 18:19 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 22:23 -0400
        Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-19 12:42 -0700
          Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-19 22:19 -0400
            Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 11:44 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 18:47 +0800
        Re: [BBC] Programmers who use spaces 'paid more' nospam@please.invalid (AnthonyL) - 2017-06-19 11:24 +0000
          Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 20:26 +0800
    Re: [BBC] Programmers who use spaces 'paid more' JJ <jj4public@vfemail.net> - 2017-06-19 20:53 +0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 22:27 +0800
      Re: [BBC] Programmers who use spaces 'paid more' Anton Shepelev <anton.txt@gmail.com> - 2017-06-21 00:51 +0300
        Re: [BBC] Programmers who use spaces 'paid more' asetofsymbols@gmail.com - 2017-06-21 04:43 -0700
          Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 05:12 -0700
    Re: [BBC] Programmers who use spaces 'paid more' Simon Wright <simon@pushface.org> - 2017-06-21 13:27 +0100
      Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 05:39 -0700
        Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 14:12 +0100
        Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 06:51 -0700
          Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 17:39 +0200
            Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 08:46 -0700
              Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 17:46 +0200
                Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 08:59 -0700
                  Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 18:11 +0200
            Re: [BBC] Programmers who use spaces 'paid more' scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 15:50 +0000
              Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 17:53 +0200
                Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 09:01 -0700
                  Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 18:16 +0200
                    Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 09:28 -0700
                Re: [BBC] Programmers who use spaces 'paid more' scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 16:37 +0000
              Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 17:40 +0100
                Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 09:48 -0700
                  Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 18:05 +0100
                    Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 11:01 -0700
                      Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 19:46 +0100
                        Re: [BBC] Programmers who use spaces 'paid more' David Kleinecke <dkleinecke@gmail.com> - 2017-06-21 12:21 -0700
                          Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 21:31 +0200
    Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-21 18:48 +0200
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-22 00:52 +0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#112740

JJ:

> Tab characters are annoying.  They messes the cur-
> sor's  column  position  when  it's  being   moved
> up/down and through the middle of the non existing
> space which was generated by the tab character.

There is a standard convention that  works  100%  of
the time:
                 Indent with tabs
                 Align with spaces

Such code will look good regardless of the tab width
used in the editor, so that each programmer may  set
up whatever tab width he prefers.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#112761

Spaces allow better 
and finer 
indentation
Than tabs

[toc] | [prev] | [next] | [standalone]

#112765

On Wednesday, June 21, 2017 at 7:43:35 AM UTC-4, asetof...@gmail.com wrote:
> Spaces allow better 
> and finer 
> indentation
> Than tabs

They also ultimately require more effort on behalf of the developer.
If you use 4 characters for a tab, then you can move something up to
three characters before the thing that's aligned to its right will
move.  This of course varies with the width of the thing initially,
but I've noticed over time that every movement with spaces alignment
requires an adjustment, but very few with tabs do.  And if you use
8 characters for tab spacing like many people do, it happens even
less frequently.

I prefer tabs across the board, and I use spaces for very fine
adjustments when you have something like this:

    this12  = something();
    that123 = otherthing();

That is:

    [tab]this12[space][space]=[space]...
    [tab]that123[space]=[space]...

And for line comments along the right, I always use tabs.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112766

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> The debate over whether it is better to use spaces or tabs to indent
> code has raged among programmers for years.

Dead simple: use the TAB key to tell the editor to align the
current/selected lines appropriately; and leave the editor to decide
whether to use tab characters (C-I) to implement the indent or just
spaces.

I agree that you have a problem if your project standards require some
weird setting, but it's still a question of customising the editor.

I bet that 90+% of the Ada programmers who've read this thread are using
GNAT, and if they are using either of the most likely editors (GPS or
Emacs) they'll have this sorted for them without any need for fretting
over it.

Anyone who argues for tabs on the grounds that they save space is
clearly living in 1987 at the latest. If you want to save space, why not
remove all comments?

[toc] | [prev] | [next] | [standalone]

#112767

On Wednesday, June 21, 2017 at 8:28:02 AM UTC-4, Simon Wright wrote:
> Anyone who argues for tabs on the grounds that they save space is
> clearly living in 1987 at the latest. If you want to save space, why not
> remove all comments?

Do a test.  Download the Linux kernel source code and replace all
of their tabs with spaces (they use 8 characters per tab).  Compare
the file size before and after.  And more importantly, compare the
number of characters that have to be parsed before and after, as
each space-whitespace character must be traversed, whereas the same
is true with each tab-whitespace, it requires up to 8x fewer steps
to move across each tab compared to whitespaces.

It doesn't make a huge difference in performance, but it does take
longer to process, is more resource intensive, and when you have
millions of users working with source code and compiling it into
binaries (as Linux and open source software projects are and do),
that translates to billions of wasted watts of power.  That, of
course assumes they're not already being wasted by whatever it is
they're doing.  Hahahaha

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112768

On 21/06/2017 13:39, Rick C. Hodgin wrote:
> On Wednesday, June 21, 2017 at 8:28:02 AM UTC-4, Simon Wright wrote:
>> Anyone who argues for tabs on the grounds that they save space is
>> clearly living in 1987 at the latest. If you want to save space, why not
>> remove all comments?
> 
> Do a test.  Download the Linux kernel source code and replace all
> of their tabs with spaces (they use 8 characters per tab).  Compare
> the file size before and after.  And more importantly, compare the
> number of characters that have to be parsed before and after, as
> each space-whitespace character must be traversed, whereas the same
> is true with each tab-whitespace, it requires up to 8x fewer steps
> to move across each tab compared to whitespaces.
> 
> It doesn't make a huge difference in performance, but it does take
> longer to process, is more resource intensive, and when you have
> millions of users working with source code and compiling it into
> binaries (as Linux and open source software projects are and do),
> that translates to billions of wasted watts of power.  That, of
> course assumes they're not already being wasted by whatever it is
> they're doing.  Hahahaha

Most code is so inefficient in terms of bloat or complexity that the 
difference between tabs and spaces is not significant.

Not when people use identifiers like this:

CRYPTNET_PRE_FETCH_VALIDITY_PERIOD_AFTER_NEXT_UPDATE_PRE_FETCH_DIVISOR_VALUE_NAME

(From mingw's windows.h.)

Can anyone beat that? I mean in actual, existing code that they've come 
across. Otherwise it would be easy to beat the 81 characters of this 
example.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112777

On Wednesday, June 21, 2017 at 8:40:19 AM UTC-4, Rick C. Hodgin wrote:
> On Wednesday, June 21, 2017 at 8:28:02 AM UTC-4, Simon Wright wrote:
> > Anyone who argues for tabs on the grounds that they save space is
> > clearly living in 1987 at the latest. If you want to save space, why not
> > remove all comments?
> 
> Do a test.  Download the Linux kernel source code and replace all
> of their tabs with spaces (they use 8 characters per tab).  Compare
> the file size before and after.  And more importantly, compare the
> number of characters that have to be parsed before and after, as
> each space-whitespace character must be traversed, whereas the same
> is true with each tab-whitespace, it requires up to 8x fewer steps
> to move across each tab compared to whitespaces.
> 
> It doesn't make a huge difference in performance, but it does take
> longer to process, is more resource intensive, and when you have
> millions of users working with source code and compiling it into
> binaries (as Linux and open source software projects are and do),
> that translates to billions of wasted watts of power.  That, of
> course assumes they're not already being wasted by whatever it is
> they're doing.  Hahahaha

Downloading the Linux kernel source code as a .ZIP file from GitHub,
and using auto-renaming on Windows for cases like this.h and THIS.h
not being two separate files in Windows as they are in Linux:

    https://github.com/torvalds/linux

Before conversion, the \linux\ folder was 731,101,008 bytes
according to Windows Explorer.

Using this tabspace utility from Stefans Tools:

    http://stefanstools.sourceforge.net/tabspace.html

It translates to actual file size:

    4-character tabs:  798,540,870 bytes, +67,439,862 bytes
    8-character tabs:  888,353,986 bytes, +157,252,978 bytes

The on-disk total file size for an NTFS partition using 8-character
tabs requires 996,642,816 bytes, up from 839,241,728 bytes, an
increase of 157,401,088 bytes.

But the raw file size (without regards to disk storage) increases
are:

    4-character tabs:  +9.2%
    8-character tabs:  +21.5%

Even with today's massive storage drives, I wouldn't want 20% of
my source code hard disk files wasted by unnecessary spaces.  Nor
would I want to need to have 20% greater machine resources to
compile the same kernel.

I don't have a native Linux box at hand where I can determine the
difference in compile-time between the tabs version and the spaces
version, but I'd be curious to see how much longer it took.

I'd also be curious to learn how much more power it took by doing
a watt-reading from the wall power compiling one to the other with
a 4x each test average.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112787

On Wed, 21 Jun 2017 06:51:29 -0700 (PDT)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> I don't have a native Linux box at hand where I can determine the
> difference in compile-time between the tabs version and the spaces
> version, but I'd be curious to see how much longer it took.

Since spaces or tabs (and comments) are processed as one single space by the C
preprocessor, I assume the difference shouldn't be significative.

[toc] | [prev] | [next] | [standalone]

#112788

On Wednesday, June 21, 2017 at 11:42:51 AM UTC-4, GOTHIER Nathan wrote:
> On Wed, 21 Jun 2017 06:51:29 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > I don't have a native Linux box at hand where I can determine the
> > difference in compile-time between the tabs version and the spaces
> > version, but I'd be curious to see how much longer it took.
> 
> Since spaces or tabs (and comments) are processed as one single space by the C
> preprocessor, I assume the difference shouldn't be significative.

I would like to know and not guess.

You must realize that every source file would be loaded into memory,
meaning 20% more memory is used, 20% more hard disk traffic, 20% more
paging entries are used, and the CPU must have bus traffic across 20%
more memory space, even if it parses those multiple spaces down to a
single generic whitespace.

I'd be curious to see what a system so large as the Linux kernel
would consume using tabs and spaces.

I don't have a meter that will register those loads, but maybe the
group at Cyberia does.  If they do, I'll do the test and find out.
If not, I can at least do the comparison in kernel compilation
times.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112790

On Wed, 21 Jun 2017 08:46:02 -0700 (PDT)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> You must realize that every source file would be loaded into memory,
> meaning 20% more memory is used, 20% more hard disk traffic, 20% more
> paging entries are used, and the CPU must have bus traffic across 20%
> more memory space, even if it parses those multiple spaces down to a
> single generic whitespace.

As previously said, I don't think the source size is relevant unless you'd like
obfuscated code without any comment.

[toc] | [prev] | [next] | [standalone]

#112793

On Wednesday, June 21, 2017 at 11:49:42 AM UTC-4, GOTHIER Nathan wrote:
> On Wed, 21 Jun 2017 08:46:02 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> 
> > You must realize that every source file would be loaded into memory,
> > meaning 20% more memory is used, 20% more hard disk traffic, 20% more
> > paging entries are used, and the CPU must have bus traffic across 20%
> > more memory space, even if it parses those multiple spaces down to a
> > single generic whitespace.
> 
> As previously said, I don't think the source size is relevant unless you'd like
> obfuscated code without any comment.

If you had a way to save 20% on your heating bill each month without
having any change whatsoever in the heat or air quality, except that
each time you changed the filter you might have to adjust the screws
a little differently than before, would you do it?

It's just one of those things:  why have waste when you don't need to?

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112796

On Wed, 21 Jun 2017 08:59:24 -0700 (PDT)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> If you had a way to save 20% on your heating bill each month without
> having any change whatsoever in the heat or air quality, except that
> each time you changed the filter you might have to adjust the screws
> a little differently than before, would you do it?

You wrongly assume space indentation don't have any sort of quality...

[toc] | [prev] | [next] | [standalone]

#112791

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>On Wed, 21 Jun 2017 06:51:29 -0700 (PDT)
>"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>
>> I don't have a native Linux box at hand where I can determine the
>> difference in compile-time between the tabs version and the spaces
>> version, but I'd be curious to see how much longer it took.
>
>Since spaces or tabs (and comments) are processed as one single space by the C
>preprocessor, I assume the difference shouldn't be significative.

If the preprocessor calls 'getc' eight times instead of one time,
there _will_ be a performance impact and a memory impact; both
may be minor for small projects, but can add up for a million SLOC
project.

[toc] | [prev] | [next] | [standalone]

#112792

On Wed, 21 Jun 2017 15:50:37 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> If the preprocessor calls 'getc' eight times instead of one time,
> there _will_ be a performance impact and a memory impact; both
> may be minor for small projects, but can add up for a million SLOC
> project.

With buffered input I doubt the performance loss would be significative.

What about the impact of comments? Would you recommend to remove them?

[toc] | [prev] | [next] | [standalone]

#112794

On Wednesday, June 21, 2017 at 11:56:59 AM UTC-4, GOTHIER Nathan wrote:
> On Wed, 21 Jun 2017 15:50:37 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
> 
> > If the preprocessor calls 'getc' eight times instead of one time,
> > there _will_ be a performance impact and a memory impact; both
> > may be minor for small projects, but can add up for a million SLOC
> > project.
> 
> With buffered input I doubt the performance loss would be significative.

I would to know and not guess.

> What about the impact of comments? Would you recommend to remove
> them?

Comments serve a visible purpose for human beings.  Spaces vs. tabs
do not.  The only time they are ever an issue is when you have to
add or remove content, at which time they may cause or not cause
you to have to do extra work to keep things aligned.

But comments provide real substance to the developer.  They should
not be removed unless you are seeking to create an optimized file
for compile-only applications, whereby the original source file
with comments is then processed through a parser which removes
those things which would slowdown compilation.  That might actually
be a nice tool to have for public distributions that don't need to
have the original source code, but just source code, so they can
be properly built on the target machines.  Hmm... interesting.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112798

On Wed, 21 Jun 2017 09:01:37 -0700 (PDT)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:

> Comments serve a visible purpose for human beings.  Spaces vs. tabs
> do not.  The only time they are ever an issue is when you have to

The visible purpose of spaces is to shape the code with the same representation
with traditional mono space characters such as in VGA text mode.

[toc] | [prev] | [next] | [standalone]

#112799

On Wednesday, June 21, 2017 at 12:19:57 PM UTC-4, GOTHIER Nathan wrote:
> On Wed, 21 Jun 2017 09:01:37 -0700 (PDT)
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
> > Comments serve a visible purpose for human beings.  Spaces vs. tabs
> > do not.  The only time they are ever an issue is when you have to
> 
> The visible purpose of spaces is to shape the code with the same representation
> with traditional mono space characters such as in VGA text mode.

"This new learning amazes me, Sir GOTHIER.  Explain again how
sheep's bladders may be employed to prevent earthquakes."

Someone in the thread has already said it.  Use tabs to get your
first alignment, then spaces thereafter.  But I argue you should
use tabs nearly all the time, except for those cases where it's
a very minor visual tweak, such as:

    this12  = ...
    that123 = ...

I would use a tab up to the "t" in both lines, then two spaces on
the first line, and one on the second, to align the equals.

But if you change that first indentation to spaces or tabs, the
human eye will never see any difference, unless you have reveal
whitespaces turned on ... and seriously, who does that all the
time? :-)

I'm curious about the Linux compile time.  We shall see, Mr.
GOTHIER ... Nathan it is! :-)

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112801

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>On Wed, 21 Jun 2017 15:50:37 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> If the preprocessor calls 'getc' eight times instead of one time,
>> there _will_ be a performance impact and a memory impact; both
>> may be minor for small projects, but can add up for a million SLOC
>> project.
>
>With buffered input I doubt the performance loss would be significative.
>
>What about the impact of comments? Would you recommend to remove them?

That's what the preprocessor _does_ (amongst other things).  Which
will speed up the subsequent lexical analysis - assuming they're separate.

[toc] | [prev] | [next] | [standalone]

#112802

On 21/06/2017 16:50, Scott Lurndal wrote:
> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>> On Wed, 21 Jun 2017 06:51:29 -0700 (PDT)
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote:
>>
>>> I don't have a native Linux box at hand where I can determine the
>>> difference in compile-time between the tabs version and the spaces
>>> version, but I'd be curious to see how much longer it took.
>>
>> Since spaces or tabs (and comments) are processed as one single space by the C
>> preprocessor, I assume the difference shouldn't be significative.
> 
> If the preprocessor calls 'getc' eight times instead of one time,
> there _will_ be a performance impact and a memory impact; both
> may be minor for small projects, but can add up for a million SLOC
> project.

I did a test on 2.5MLoc, repeats of this line:

   a=a*b^c;

each preceded by either eight spaces or one tab.

Full compilation with Tiny C took about 7% longer with the spaces (an 
extra 0.25 seconds).

With my preprocessor, only doing preprocessing took 6% longer with the 
spaces (about 50ms longer). With a full compile, it would be harder to 
measure the difference.

But this is with a test input where nearly half the input consists of 
these leading spaces. More typical input will have a lower mix of 
leading spaces.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112804

On Wednesday, June 21, 2017 at 12:40:57 PM UTC-4, Bart wrote:
> Full compilation with Tiny C took about 7% longer with the spaces (an 
> extra 0.25 seconds).

I believe TinyC is able to compile the Linux kernel.  Can you try
to see how it goes with tabs and 8-spaces-per-tab?

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web