-
Notifications
You must be signed in to change notification settings - Fork 182
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
small perf improvements #1490
small perf improvements #1490
Conversation
@@ -378,7 +378,7 @@ def batch_insert_record( | |||
self.orm.Record.parse(r, redact_keys=self.redact_keys) | |||
for r in records | |||
] | |||
session.bulk_save_objects(records_list) | |||
session.add_all(records_list) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats difference between add_all and bulk_save objects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functionally the same thing. bulk_save_objects is the legacy API in SQLAlchemy 2.0 so updated this to use the add_all
API.
for finfo in inspect.stack()[offset + 1 :]: | ||
if not finfo.frame.f_globals["__name__"].startswith("trulens"): | ||
return finfo.frame | ||
gen = list(stack_generator(offset + 2)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
casting to a list shouldn't be necessary here right? and it's more memory efficient if you just iterate over the generator without forcing to evaluate the entire stack gen at once
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was originally thinking the same. Then realized that because the generator is called lazily, its call stack would change and reflect the generator callee's call stack, not the call stack of external_caller_frame
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah got it sg - could you add a small comment in the code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually we may be able to get around this by passing in the current frame so that inspect.currentframe() is guarenteed to be invoked at the right time (pre-generator)
left a few minor comments. mostly LGTM |
* small perf improvements * nonetype check * write api * revert * stack_generator should take in callee's frame * skip first
Description
Other details good to know for developers
Please include any other details of this change useful for TruLens developers.
Type of change
not work as expected)