2 ms·

I recommend reducing the warning limit on slow compilation in Swift. -Xfrontend -warn-long-function-bodies=<limit-ms> -Xfrontend -warn-long-expression-type

I recommend reducing the warning limit on slow compilation in Swift. -Xfrontend -warn-long-function-bodies=<limit-ms> -Xfrontend -warn-long-expression-type-checking=<limit-ms> Set these to ~100ms and add a few explicit types whenever they log, and compile time will be significantly improved. Swift is a slow compiler in exceptional cases, maybe in the 99th percentile, but when you know where this is happening it's fairly trivial to avoid it and keep the compiler nimble and stay productive as an engineer.

iainmerrick 3y ago
In this particular case, adding an explicit type didn’t help at all. I’ve worked in a large Swift project with those timeout warnings enabled, and didn’t find them too helpful. They showed up a lot and it was rarely obvious how to quickly fix them. Possibly it would have been useful if those warnings were enabled from the start and developers had always fixed them proactively. I’m skeptical that that could work in a big fast-moving team project, though.
- danpalmer 3y ago
  I think it's reasonable to have a warnings-are-errors approach even in medium sized teams, or if not quite that approach perhaps a "warnings go in the bug tracker" approach. I'm far from a Swift expert, but I usually found I could reduce the compilation time with ~10 mins of work. When I turned these on for a small codebase (60k lines, ~50% of an engineer split across 3 people), it only took a few hours to solve all the instances of this, and they were mostly obvious cases where a 100 line function could be split into 3 and solve the issue.
  - addaon 3y ago
    Warnings-as-errors is a great policy in general, but these are non-deterministic warnings based on compile time wall timing. Coworker working on a slower computer than you? He can run into hundreds of errors after a pull that you introduced but couldn't see, what now? Running something intensive in the background? You can't compile successfully any more. Not ideal.
    - danpalmer 3y ago
      That's true, but a setting of 100ms is a few orders of magnitude higher than expressions should be so it's quite possible to make this fairly reliable.
      - addaon 3y ago
        The problem is that if this ever catches anything, then there's things that it almost catches. And you have no way of telling if you have something expression that takes 99 ms on your machine, so will take 101 ms on your coworkers'. The appropriate way to deal with this in general is to have separate warning and error thresholds, where the difference between the two is greater than the variance between machines, e.g. 50 ms and 100 ms; at least in this case when your coworker checks out a broken build he can see that warnings were introduced in your commit in a CI build log and track it down to the source.
        danpalmer 3y ago
        It's easy to have one setting for local development and one for CI. Xcode supports different profiles natively so you can just put 50ms or whatever in your user settings and leave 100ms or even 1s in your standard build settings. Also, this sort of works the other way too. Just because something failed at the 100ms threshold doesn't mean it would complete in 101ms, it might take 500ms, 10 minutes, or be undecidable, and it's important to fail CI in those sorts of cases to protect other developers from issues, so having a limit is useful even if it's relatively high for the default case.
        addaon 3y ago
        I guess I don't see what the actual workflow is supposed to be for a new team member who joins (potentially with a different computer than everyone else), checks out the code, and has dozens of errors when they first try to build. I'm a huge fan of error'ing on warnings, but I really don't see it as appropriate for nondeterministic cases.
titzer 3y ago
> it's fairly trivial to avoid it and keep the compiler nimble Personally I think it's the job of tools to make humans productive instead of the other way around.
- danpalmer 3y ago
  I see what you mean, but in this case it's that the Swift compiler is keeping you productive by doing a ton of work for you, and asking for a little clarity every now and again so that it doesn't have to do exhaustive searches of what you mean.
deleted 3y ago
[deleted]

iainmerrick 3y ago

In this particular case, adding an explicit type didn’t help at all. I’ve worked in a large Swift project with those timeout warnings enabled, and didn’t find them too helpful. They showed up a lot and it was rarely obvious how to quickly fix them. Possibly it would have been useful if those warnings were enabled from the start and developers had always fixed them proactively. I’m skeptical that that could work in a big fast-moving team project, though.

danpalmer 3y ago
I think it's reasonable to have a warnings-are-errors approach even in medium sized teams, or if not quite that approach perhaps a "warnings go in the bug tracker" approach. I'm far from a Swift expert, but I usually found I could reduce the compilation time with ~10 mins of work. When I turned these on for a small codebase (60k lines, ~50% of an engineer split across 3 people), it only took a few hours to solve all the instances of this, and they were mostly obvious cases where a 100 line function could be split into 3 and solve the issue.
- addaon 3y ago
  Warnings-as-errors is a great policy in general, but these are non-deterministic warnings based on compile time wall timing. Coworker working on a slower computer than you? He can run into hundreds of errors after a pull that you introduced but couldn't see, what now? Running something intensive in the background? You can't compile successfully any more. Not ideal.
  - danpalmer 3y ago
    That's true, but a setting of 100ms is a few orders of magnitude higher than expressions should be so it's quite possible to make this fairly reliable.
    - addaon 3y ago
      The problem is that if this ever catches anything, then there's things that it almost catches. And you have no way of telling if you have something expression that takes 99 ms on your machine, so will take 101 ms on your coworkers'. The appropriate way to deal with this in general is to have separate warning and error thresholds, where the difference between the two is greater than the variance between machines, e.g. 50 ms and 100 ms; at least in this case when your coworker checks out a broken build he can see that warnings were introduced in your commit in a CI build log and track it down to the source.
      - danpalmer 3y ago
        It's easy to have one setting for local development and one for CI. Xcode supports different profiles natively so you can just put 50ms or whatever in your user settings and leave 100ms or even 1s in your standard build settings. Also, this sort of works the other way too. Just because something failed at the 100ms threshold doesn't mean it would complete in 101ms, it might take 500ms, 10 minutes, or be undecidable, and it's important to fail CI in those sorts of cases to protect other developers from issues, so having a limit is useful even if it's relatively high for the default case.
        addaon 3y ago
        I guess I don't see what the actual workflow is supposed to be for a new team member who joins (potentially with a different computer than everyone else), checks out the code, and has dozens of errors when they first try to build. I'm a huge fan of error'ing on warnings, but I really don't see it as appropriate for nondeterministic cases.

titzer 3y ago

> it's fairly trivial to avoid it and keep the compiler nimble Personally I think it's the job of tools to make humans productive instead of the other way around.

danpalmer 3y ago
I see what you mean, but in this case it's that the Swift compiler is keeping you productive by doing a ton of work for you, and asking for a little clarity every now and again so that it doesn't have to do exhaustive searches of what you mean.

deleted 3y ago

[deleted]