Currently largest .m file is DBTeamLogObjects.m - more than 180K lines of code with more than 5MB raw text. It alone takes more than 30 seconds to compile with Xcode14 on 3,2 GHz 6-Core Intel Core i7 Mac.
Second largest .m file is DBTeamObjects.m - more than 40K lines of code.
As these files are autogenerated anyway, it would be great if they would be splitted into multiple implementation (.m) parts that would make compilation of the library (and projects including it) multiple times faster thanks to parallelization of Xcode compilation. Also Xcode navigation features would not freeze trying to navigate these monsters.
This would make significant impact improving build times for every project using the library. Example: https://twitter.com/russshanahan/status/1592352159135191040
Currently largest .m file is DBTeamLogObjects.m - more than 180K lines of code with more than 5MB raw text. It alone takes more than 30 seconds to compile with Xcode14 on 3,2 GHz 6-Core Intel Core i7 Mac.
Second largest .m file is DBTeamObjects.m - more than 40K lines of code.
As these files are autogenerated anyway, it would be great if they would be splitted into multiple implementation (.m) parts that would make compilation of the library (and projects including it) multiple times faster thanks to parallelization of Xcode compilation. Also Xcode navigation features would not freeze trying to navigate these monsters.
This would make significant impact improving build times for every project using the library. Example: https://twitter.com/russshanahan/status/1592352159135191040