Request for documentation, or user experiences, optimizing build_runnner

[Adam-Langley]

Hi community!

I have been utilising drift for several months now, and my client-side database has become quite large (schematically).

My ".g.dart" file, produced by drift_dev, is now 55k lines of dart code!

Runtime, I have no complaints - but the build_runner does take at least 2 minutes to execute any time I change something.

I did used to have everything in a single dart file (except for a drift file for views, and one for some complex queries) - and that took over 5 minutes to run - so I have improved somewhat.

I'd like to describe how I reduced that time here, and would love to hear your own similar experiences - perhaps this could eventually go into a best practice guide.

My drift database has 74 tables, 4 daos, and 2 included drift files for views and custom queries.

The best boost I got, was moving all my tables into separate files. I grouped them into files of similar concern (rather than having 74 small files!) - I'm not sure if having 74 small files would be more performant than what I have (6 files with about 6 tables in each - then some leftover tables in the main database .dart file)
That did cause my project to look a little cluttered, and I went to put all these files into a sub-folder, but hit the issue that ".drift" files cannot "include" from a subpath ("/" token syntax not supported by drift parser) - but that is easily resolved, by creating a single dart file in the same folder as the .drift, which "exports" the darts from the sub-folder - you can then include that single file into your drift.

Love to hear any tricks anyone else has observed!

[simolus3]

but hit the issue that ".drift" files cannot "include" from a subpath ("/" token syntax not supported by drift parser)

This sounds like an issue worth fixing. Does import 'subdirectory/nested/other/drift/file.drift'; not work? Imports in drift files should support the same URL syntax as imports in Dart.

Love to hear any tricks anyone else has observed!

For complex builds, I can recommend checking out the modular build mode as well. Instead of drift generating a single .g.dart file containing every table, you can make it generate separate files for every input .dart or .drift file defining a table or other things of interest. It requires some changes to the code since these are no longer part files but independent libraries with their own imports, but that option has been designed to make incremental rebuilds faster.

[Adam-Langley]

Thanks Simon,

Correct, the tokenizer appears to hiccup as soon as it reaches a "/" character in the import.
I only had one folder deep:

import 'tables/mytable.dart'

And it generated a syntax error.
Sorry for the lack of detail - I'm not in front of my computer right now...

Thanks for pointing out the modular feature.
For my specific use case, I actually generate all my table definitions from a swagger file - it means I use dart based drift tables, rather than ".drift" file definitions.

It looks like the modular feature is intended for the ".drift" file use case - is that correct, or will it work for me?

While I technically could rewrite my code generators to produce drift instead of dart, I would prefer not to...for technical reasons, not only to avoid the work 😃

Thanks

[Mike278]

Love to hear any tricks anyone else has observed!

We have a very large project so using generate_for dropped our build time from 3mins to 30secs

[Adam-Langley]

Thanks @Mike278 - thats definitely a good one to remember.

[simolus3]

And it generated a syntax error.

If you get the chance, could you post the syntax error here or in a new issue? I couldn't reproduce it with that import in a drift file, and this sounds like something worth fixing.

[Adam-Langley]

Hi @simolus3
Odd - I had rolled my code back to where I experimented with using sub-folders - and just could not get it to produce the same syntax error. I expect this may have hence been the result of some stale caching - I have seen generators (including my own bespoke ones) get out of sync before, and a full clean is required to resolve.