This message was deleted.

Simply modularizing the project is not a guarantee to faster builds. Each module need to build all the other modules it depends before being built. Therefore, the key here is how each module depend in each other. It needs to be modularized carefully so you limit the number of modules depending between each other, maximizing the amount of modules that can be compiled in parallel. You can see your module dependencies graph as a tree, where the main app module is the root. Then, your goal is to reduce the heigh of your tree from the root to the leaves. Ideally 3-4 levels at most. If you are not sure about your modules graph, you can use this plugin (and I encourage you reading also its documentation, as it also has some recommendations to achieve what I was describing above). And you are quite correct when you mention that each module comes with some overhead. So think carefully which modules make sense for your project and try to be lean, not abusing of modules with just a few files.

Do we mean overhead by configuration time or execution time also needs to pay this cost? Yes we’re using that plugin and we’re making sure our current height ie 6 should not increase and also have rules in placed to avoid unnecessary dependency . But the point I’m making here let’s say you have 2,00,000 LOC in your app module and you create a new module out from app which has 10,000 LOC now the newly create module is taking 20-25 to compile but if you look at the build time of app module in gradle scan is not reducing. Ideally app module build time also should reduced by 20-25 sec.

Not an expert in how gradle compiles, but I don’t think the build times are comparable linearly in the way you expect. The time building 10k isolated lines doesn’t need to be the same as building 10K as part of a bigger chunk of 200k. So if the new module is taking 25 sec, maybe you might just get 5 back in the main app module. It might be not significant step by step, but would be noticeable after some more modules are extracted. At the end you need you are creating a more complex system, and you need to spawn other workers to build those modules, so they might need to catch-up and produce some duplicated stuff. This should not be compared serially, but by having the modules gives the system the chance to run all of this in parallel. So even if the total computational time of all modules is higher, the total time of the whole build would eventually be smaller. In any case, you will notice this benefit more for incremental/cached builds (where only a subpart of the modules needs to be built). This is one of the key reasons to modularize, as engineers working only in a module will just need to compile a subset of the project.

got it thanks