β² 335 βΌ The Creator of Git and Linux (thelemmy.club) submitted 4 hours ago by rulray@lemmy.dbzer0.com to c/linuxmemes@lemmy.world 82 comments fedilink hide all child comments
[β] Pomal@sh.itjust.works 22 points 3 hours ago (1 child) permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 3 points 3 hours ago* (last edited 3 hours ago) (3 children) I think that there's a legit rejoinder of "Why aren't you optimizing the code to reduce compilation time, if it's such a problem?" For something like C++, ccache, distcc, PIMPL (to reduce use of templates, which blows up C++ compilation time), precompiled headers, make code more modular to reduce the size of the compilation unit that changes when any one change happens, break stuff into libraries, etc. Look to see whether there are things like build timestamps being inserted into headers that are producing unnecessary recompilations. clang and gcc can profile compilations to identify what's chewing up time. permalink fedilink source parent hideshow 6 child comments replies: [β] luciferofastora@feddit.org 3 points 1 hour ago Taking a comic about a flimsy excuse and doing a serious analysis of a joke problem is such an xkcd thing to do. permalink fedilink source parent [β] lime@feddit.nu 15 points 3 hours ago (1 child) that xkcd comic is coming up on 20 years old. most computers didn't have multiple cores yet. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 1 point 3 hours ago* (1 child) I mean, none of the optimizations I listed rely on multiple cores. It's true that just running parallel compilation jobs on your build machine is a simple way to speed things up, no disagreement, but it's not like optimizing compilation time isn't a thing outside of that. permalink fedilink source parent hideshow 2 child comments replies: [β] lime@feddit.nu 2 points 2 hours ago* (1 child) i was thinking more about tooling, most of that stuff didn't exist as widely as today and you couldn't really look for it when waiting for a compile either. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 2 points 2 hours ago* Well...the in-compiler time analysis I think wasn't as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available. I dunno how far back distcc goes. checks git repository The git log goes back to 2008, so almost 20 years, but it's also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn't get imported. Wikipedia says that ccache goes back 24 years. permalink fedilink source parent [β] grue@lemmy.world 2 points 1 hour ago In my experience, [proprietary] projects are doing well if their Makefile isn't so broken that they have to run it twice just to make sure everything actually compiles. And you want them to actually optimize it...?! permalink fedilink source parent
[β] tal@lemmy.today 3 points 3 hours ago* (last edited 3 hours ago) (3 children) I think that there's a legit rejoinder of "Why aren't you optimizing the code to reduce compilation time, if it's such a problem?" For something like C++, ccache, distcc, PIMPL (to reduce use of templates, which blows up C++ compilation time), precompiled headers, make code more modular to reduce the size of the compilation unit that changes when any one change happens, break stuff into libraries, etc. Look to see whether there are things like build timestamps being inserted into headers that are producing unnecessary recompilations. clang and gcc can profile compilations to identify what's chewing up time. permalink fedilink source parent hideshow 6 child comments replies: [β] luciferofastora@feddit.org 3 points 1 hour ago Taking a comic about a flimsy excuse and doing a serious analysis of a joke problem is such an xkcd thing to do. permalink fedilink source parent [β] lime@feddit.nu 15 points 3 hours ago (1 child) that xkcd comic is coming up on 20 years old. most computers didn't have multiple cores yet. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 1 point 3 hours ago* (1 child) I mean, none of the optimizations I listed rely on multiple cores. It's true that just running parallel compilation jobs on your build machine is a simple way to speed things up, no disagreement, but it's not like optimizing compilation time isn't a thing outside of that. permalink fedilink source parent hideshow 2 child comments replies: [β] lime@feddit.nu 2 points 2 hours ago* (1 child) i was thinking more about tooling, most of that stuff didn't exist as widely as today and you couldn't really look for it when waiting for a compile either. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 2 points 2 hours ago* Well...the in-compiler time analysis I think wasn't as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available. I dunno how far back distcc goes. checks git repository The git log goes back to 2008, so almost 20 years, but it's also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn't get imported. Wikipedia says that ccache goes back 24 years. permalink fedilink source parent [β] grue@lemmy.world 2 points 1 hour ago In my experience, [proprietary] projects are doing well if their Makefile isn't so broken that they have to run it twice just to make sure everything actually compiles. And you want them to actually optimize it...?! permalink fedilink source parent
[β] luciferofastora@feddit.org 3 points 1 hour ago Taking a comic about a flimsy excuse and doing a serious analysis of a joke problem is such an xkcd thing to do. permalink fedilink source parent
[β] lime@feddit.nu 15 points 3 hours ago (1 child) that xkcd comic is coming up on 20 years old. most computers didn't have multiple cores yet. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 1 point 3 hours ago* (1 child) I mean, none of the optimizations I listed rely on multiple cores. It's true that just running parallel compilation jobs on your build machine is a simple way to speed things up, no disagreement, but it's not like optimizing compilation time isn't a thing outside of that. permalink fedilink source parent hideshow 2 child comments replies: [β] lime@feddit.nu 2 points 2 hours ago* (1 child) i was thinking more about tooling, most of that stuff didn't exist as widely as today and you couldn't really look for it when waiting for a compile either. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 2 points 2 hours ago* Well...the in-compiler time analysis I think wasn't as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available. I dunno how far back distcc goes. checks git repository The git log goes back to 2008, so almost 20 years, but it's also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn't get imported. Wikipedia says that ccache goes back 24 years. permalink fedilink source parent
[β] tal@lemmy.today 1 point 3 hours ago* (1 child) I mean, none of the optimizations I listed rely on multiple cores. It's true that just running parallel compilation jobs on your build machine is a simple way to speed things up, no disagreement, but it's not like optimizing compilation time isn't a thing outside of that. permalink fedilink source parent hideshow 2 child comments replies: [β] lime@feddit.nu 2 points 2 hours ago* (1 child) i was thinking more about tooling, most of that stuff didn't exist as widely as today and you couldn't really look for it when waiting for a compile either. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 2 points 2 hours ago* Well...the in-compiler time analysis I think wasn't as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available. I dunno how far back distcc goes. checks git repository The git log goes back to 2008, so almost 20 years, but it's also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn't get imported. Wikipedia says that ccache goes back 24 years. permalink fedilink source parent
[β] lime@feddit.nu 2 points 2 hours ago* (1 child) i was thinking more about tooling, most of that stuff didn't exist as widely as today and you couldn't really look for it when waiting for a compile either. permalink fedilink source parent hideshow 2 child comments replies: [β] tal@lemmy.today 2 points 2 hours ago* Well...the in-compiler time analysis I think wasn't as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available. I dunno how far back distcc goes. checks git repository The git log goes back to 2008, so almost 20 years, but it's also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn't get imported. Wikipedia says that ccache goes back 24 years. permalink fedilink source parent
[β] tal@lemmy.today 2 points 2 hours ago* Well...the in-compiler time analysis I think wasn't as good then, though I recall doing my own ad-hoc profiling, logging time for each unit. But the refactoring stuff should be available. I dunno how far back distcc goes. checks git repository The git log goes back to 2008, so almost 20 years, but it's also talking about release 3.0 then, so there might have been time outside a VCS or with history that didn't get imported. Wikipedia says that ccache goes back 24 years. permalink fedilink source parent
[β] grue@lemmy.world 2 points 1 hour ago In my experience, [proprietary] projects are doing well if their Makefile isn't so broken that they have to run it twice just to make sure everything actually compiles. And you want them to actually optimize it...?! permalink fedilink source parent
