Issue 66652 - Potential speed up possibility for mkdepend
Summary: Potential speed up possibility for mkdepend
Status: CLOSED DUPLICATE of issue 66651
Alias: None
Product: Build Tools
Classification: Code
Component: solenv (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-22 15:33 UTC by jens-heiner.rechtien
Modified: 2013-08-07 15:34 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description jens-heiner.rechtien 2006-06-22 15:33:41 UTC
Currently we call mkdpend once for each file to be compiled. The mkdepend
documentation suggests that it might be worthwhile to call mkdepend for all
files in one makefile at once.

==== snippet from mkdepend.man ====

     The approach used in this program enables it to run an order
     of  magnitude faster than any other "dependency generator" I
     have ever seen.  Central to this performance are two assump-
     tions:  that all files compiled by a single makefile will be
     compiled with roughly the same -I and -D options;  and  that
     most  files  in  a single directory will include largely the
     same files.

     Given these assumptions, makedepend  expects  to  be  called
     once for each makefile, with all source files that are main-
     tained by the makefile appearing on the  command  line.   It
     parses  each source and include file exactly once, maintain-
     ing an internal symbol table for each.  Thus, the first file
     on the command line will take an amount of time proportional
     to the amount of time that a normal  C  preprocessor  takes.
     But  on  subsequent files, if it encounter's an include file
     that it has already parsed, it does not parse it again.

==== end snippet from mkdepend.man ====
Comment 1 jens-heiner.rechtien 2006-06-23 10:51:22 UTC
Duplicate because of unpatient clicking ...

*** This issue has been marked as a duplicate of 66651 ***
Comment 2 jens-heiner.rechtien 2006-06-23 10:52:02 UTC
Closing.