On Mon, Jun 21, 2021 at 2:54 AM José Valim <jose.va...@dashbit.co> wrote:
> Hi Marc-André! > > There is no particular reason, this is a functionality that could be > added. In particular we can continue checking the mtime and file size but > compare the contents if the mtime changed but the file size is the same. > Yep 👍 > I also think we should update the mtime anyway, even if the hash is the > same. WDYT? > Yes, otherwise we might keep re-hashing the file over and over again. > Feel free to open up an issue or, if you want to tackle it, even send a PR! > Awesome. I'll check if I can come up with a PR in the next few days, and if not I'll create an issue. Thanks. It's so awesome to get such quick feedback 💛 > > Thanks! > > On Mon, Jun 21, 2021 at 8:20 AM Marc-André Lafortune < > marc-an...@marc-andre.ca> wrote: > >> I'm a newbie, sorry if this has been asked before but I couldn't find >> anything. >> >> Currently, elixir uses last modification dates to determine files that >> need to be recompiled. >> >> ``` >> $ mix compile >> # ... >> $ touch lib/some/file.ex >> $ mix compile >> Compiling <n> files (.ex) >> ``` >> >> Could Elixir not verify that in addition to a modification time change, >> that the actual text content has changed by comparing a hash of it? In the >> example above, the file `lib/some/file.ex` would be hashed a second time, >> but no recompilation would occur. >> >> Currently, many operations may change the last modification date even if >> no content at all has changed: >> * switch to a different branch, switch back >> * do an interactive rebase: >> - to rewrite a commit message, >> - to reorder some commits >> - to squash some commits together >> - etc. >> >> While the content of the files does not change (at all) in these >> examples, some very long recompilations may occur because elixir only >> relies only on modification times and not on file hashes. >> Hashing a file is orders of magnitude faster than compiling it, and >> realizing that the potentially large number of compile-time dependencies of >> a given file do not need to be recompiled is infinitely faster than >> recompiling them all for nothing. >> >> I am presuming that hash collisions are deemed so incredible unlikely to >> be acceptable, but if not, then I'd ask the same question but with using >> the complete content of the source file instead of a hash of it. Copying a >> source file is again an order of magnitude faster than the time it takes to >> recompile it. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/e7a68d8d-0102-483d-a4ec-58849eb88ef6n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/e7a68d8d-0102-483d-a4ec-58849eb88ef6n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/8-30JVn_8M0/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-_BRhadhXVckZ5TX4wLqgmxm-iuGHQr4M5Kdq4xM_1w%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-_BRhadhXVckZ5TX4wLqgmxm-iuGHQr4M5Kdq4xM_1w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CADwvmaWP%2BccDF9QRdDfL8_B8fXuFXeFSL-fV0vLgOVqFH8LiHw%40mail.gmail.com.
