Path: csiph.com!1.us.feeder.erje.net!feeder.erje.net!2.us.feeder.erje.net!weretis.net!feeder6.news.weretis.net!news.glorb.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Re: Alternative C compilers on x86_64 Linux? Date: Fri, 30 Sep 2016 05:03:53 +0200 Organization: Compilers Central Lines: 17 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-044@comp.compilers> References: <16-09-001@comp.compilers> <16-09-033@comp.compilers> <16-09-034@comp.compilers> <16-09-035@comp.compilers> <16-09-037@comp.compilers> <16-09-042@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="24836"; mail-complaints-to="abuse@iecc.com" Keywords: C, performance Posted-Date: 29 Sep 2016 23:22:51 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1783 BartC schrieb: > (I can tokenise C source code at some 10M lines per second on my PC > (this excludes symbol table lookups; just raw tokenising). But gcc might > process the same source at only 10K lines per second, even excluding > dealing with headers. IMO it's not the header files, which slow down compilation, but the preprocessor macros which require to look up and optionally expand every token. Almost every language has to allow for external references, which are read from some shared file. Next comes the amount of declarations in the standard C header files, which require much memory and can cause swapping, even if only a very small subset of all declarations is actually used in source code. In so far I don't think that it's fair or meaningful to compare a full blown compiler with a bare tokenizer. DoDi