GProfiling function performance
I have an app that I'm aiming to move from Firebase to Convex. Functionality-wise, the migration is nearly complete.
The Convex version is nicer in every way and there are a bunch of features I'd like to add that I expect will be much easier to implement with Convex than with Firebase.
Before committing, though, I'm trying to satisfy myself that the Convex version of the app will be viable from a performance and cost point of view. I've got a handful of specific questions, which I'll try breaking up into separate support threads.
My app essentially presents a large data set and provides affordances for zeroing in on items of interest via tag-based filtering. The Firebase version, out of necessity, does a lot of manual preprocessing, computing the items returned for combinations of tags and storing them in the database. In the Convex version, I'm hoping to avoid that, instead relying on Convex's close-to-the-db backend logic and query caching to yield good performance while keeping the implementation much simpler.
I'll ask caching questions in another thread, but first I'm wondering if there's any guidance on doing fine-grained performance profiling within a function. My current implementation features highly normalized data; the query driving the main view loops through the base data set, does per-item db reads to retrieve tags, filters items by tag, and finally loads additional fields for the filtered items. Performance in the uncached case is borderline acceptable. I can think of ways to improve it, mainly via different flavors of denormalization, but before going down the path of trying these, I'd ideally like to collect some data on where my execution time is currently being spent.
My naive attempts to collect / log timing data have been thwarted by the limitations of the runtime that guarantee deterministic query execution. Is there any alternative?
The Convex version is nicer in every way and there are a bunch of features I'd like to add that I expect will be much easier to implement with Convex than with Firebase.
Before committing, though, I'm trying to satisfy myself that the Convex version of the app will be viable from a performance and cost point of view. I've got a handful of specific questions, which I'll try breaking up into separate support threads.
My app essentially presents a large data set and provides affordances for zeroing in on items of interest via tag-based filtering. The Firebase version, out of necessity, does a lot of manual preprocessing, computing the items returned for combinations of tags and storing them in the database. In the Convex version, I'm hoping to avoid that, instead relying on Convex's close-to-the-db backend logic and query caching to yield good performance while keeping the implementation much simpler.
I'll ask caching questions in another thread, but first I'm wondering if there's any guidance on doing fine-grained performance profiling within a function. My current implementation features highly normalized data; the query driving the main view loops through the base data set, does per-item db reads to retrieve tags, filters items by tag, and finally loads additional fields for the filtered items. Performance in the uncached case is borderline acceptable. I can think of ways to improve it, mainly via different flavors of denormalization, but before going down the path of trying these, I'd ideally like to collect some data on where my execution time is currently being spent.
My naive attempts to collect / log timing data have been thwarted by the limitations of the runtime that guarantee deterministic query execution. Is there any alternative?
