Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BartyCrouch runs much slower with Xcode 10.2 #128

Closed
fredpi opened this issue Apr 2, 2019 · 10 comments · Fixed by #132
Closed

BartyCrouch runs much slower with Xcode 10.2 #128

fredpi opened this issue Apr 2, 2019 · 10 comments · Fixed by #132

Comments

@fredpi
Copy link
Contributor

fredpi commented Apr 2, 2019

Since the update to Xcode 10.2, it feels like BartyCrouch runs much slower than previously.

Times like this happen on every build of a project where BartyCrouch once didn't noticeably delay builds with Xcode 10.1:

  • Task 'Update Interfaces' took 3.45 seconds.
  • Task 'Code Transform' took 11.587 seconds.
  • Task 'Normalize' took 22.055 seconds.
  • Task 'Lint' took 22.768 seconds.

Make BartyCrouch fast again! 🥇

@Jeehut
Copy link
Member

Jeehut commented Apr 3, 2019

Thanks @fredpi for reporting this. I will investigate shortly, I didn't notice any slowdowns in BartyCrouch and the reported times are definitely a no-go. Could you please tell me how exactly you installed BartyCrouch? Did you use brew install/upgrade bartycrouch? Swift code optimizations may play an important role regarding performance ...

@fredpi
Copy link
Contributor Author

fredpi commented Apr 3, 2019

@Dschee Thanks for looking into this.

I installed BartyCrouch via brew install and recently upgraded to version 4.0.1 via brew upgrade.

@donnellyk
Copy link

donnellyk commented Apr 11, 2019

In trying to upgrade to BartyCrouch 4.0, we also saw some slowdown in Xcode 10.2

kevin-3:ios [kd/string_test]$bartycrouch update -v
Starting Task 'Update Code' ...
2019-04-11 12:16:50.048: ℹ️  Incrementally updated keys of file '/Users/kevin/git/ios/Foo/de.lproj/Localizable.strings'.
2019-04-11 12:17:00.398: ℹ️  Incrementally updated keys of file '/Users/kevin/git/ios/Foo/ja.lproj/Localizable.strings'.
2019-04-11 12:17:09.753: ℹ️  Incrementally updated keys of file '/Users/kevin/git/ios/Foo/en.lproj/Localizable.strings'.
2019-04-11 12:17:19.280: ℹ️  Incrementally updated keys of file '/Users/kevin/git/ios/Foo/es.lproj/Localizable.strings'.
2019-04-11 12:17:28.730: ℹ️  Incrementally updated keys of file '/Users/kevin/git/ios/Foo/fr.lproj/Localizable.strings'.
2019-04-11 12:17:38.425: ✅  ./Foo:  Successfully updated strings file(s) of Code files.
Task 'Update Code' took 66.402 seconds.

I believe the previous version we were on, 3.something (kinda old) was in the range of 5 seconds. We have a pretty big project, something in the order of 1500 swift files and our localizable strings files are ~3000 lines.

Looks like most of the time is spent writing the files?

Installed via brew, 4.0.1

@fredpi
Copy link
Contributor Author

fredpi commented May 10, 2019

Today, I investigated a bit about this issue and found out that while the following line performs quickly, times add up so that it accounts for an estimated 80 - 90 % of the run times.

https://github.com/Flinesoft/BartyCrouch/blob/b16ee0255908b9d0bf27b76126d42112b472a717/Sources/BartyCrouchKit/FileHandling/StringsFileUpdater.swift#L346

The .count at the end doesn't do much harm; .prefix is about 2,5x fast than .components. I've tried multiple approaches to make things faster but didn't come up with something relevant yet. As for the components().count: We could use .filter { $0 == "\n" }, but that still leaves the .prefix...

@fredpi
Copy link
Contributor Author

fredpi commented May 10, 2019

Here are two approaches, that don't make things faster:

var idx = string.startIndex
var line: Int = 0
while idx < string.index(string.startIndex, offsetBy: valueRange.location) {
    if string[idx] == "\n" { line += 1 }
    string.formIndex(after: &idx)
}
var line: Int = 1
for index in 0 ..< string.count {
    if index >= valueRange.location { break }
    if string[string.index(string.startIndex, offsetBy: index)] == "\n" {
        line += 1
     }
}

@fredpi
Copy link
Contributor Author

fredpi commented May 10, 2019

I just did another measurement by removing the heavy line calculation and found out that 'Normalize' only took 0.373 sec (compared to ~22 sec previously). If we can't find a solution to make the calculation much faster, maybe there should be an option not to calculate the line...

Jeehut added a commit that referenced this issue May 13, 2019
@Kondamon
Copy link
Contributor

Kondamon commented Sep 2, 2019

This fix doesn't work for me. I still get Task 'Code Transform' took 21.23 seconds with BartyCrouch 4.0.2, same as @fredpi.

@Jeehut
Copy link
Member

Jeehut commented Sep 2, 2019

@Kondamon Is the normalize task slow for you, too?

@Kondamon
Copy link
Contributor

Kondamon commented Sep 2, 2019

@Kondamon Is the normalize task slow for you, too?
No, the normalize task finishes extremly fast without any delay (<0.1 sec). I don't even receive a message for how long it took in the console.

@Jeehut
Copy link
Member

Jeehut commented Sep 2, 2019

Okay, in that case, could you please open a new issue specifically stating that the code transform task is slow for you? Also could you provide your configuration file contents and Xcode, macOS and BartyCrouch versions there? Additionally, a guess about how many files or code lines your project contains would be helpful, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants