-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
feat: emit files on demand and cache emit in sqlite db #15198
Conversation
We should have an alternative way of inspecting emit |
@nayeemrmn we're going to add it to here: https://deno.land/x/deno_cache Also, I'm thinking to develop a web server that can be run locally to look at the cache contents (maybe something in the deno_cache repo that can be run from the command line), but even just using something like DB Browser for SQLite is not too bad. |
I inspect emit often, though usually for checking transpilation/cache bugs. My workflow of |
@nayeemrmn yeah for sure. That would be really easy to do |
pub struct CliModuleLoader { | ||
pub lib: TsTypeLib, | ||
/// The initial set of permissions used to resolve the static imports in the | ||
/// worker. They are decoupled from the worker (dynamic) permissions since | ||
/// read access errors must be raised based on the parent thread permissions. | ||
pub root_permissions: Permissions, | ||
pub ps: ProcState, | ||
// the emit cache can only be used on one thread due to sqlite constraints | ||
emit_cache: EmitCache, |
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 had to move a lot out of proc_state and into this file because EmitCache
can only be used on a single thread whereas ProcState gets sent around all over the place.
), | ||
err | ||
); | ||
Self(None) |
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.
A nice thing is the code can work fine without an emit cache now.
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.
Are there any tests that demonstrate this? Like a read only cache dir? Feels like creating a tmp dir without read permissions would be a good test to ensure that code can still be emitted, just not cached.
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.
No, but that would be good. I will add one.
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.
some thoughts and questions
), | ||
err | ||
); | ||
Self(None) |
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.
Are there any tests that demonstrate this? Like a read only cache dir? Feels like creating a tmp dir without read permissions would be a good test to ensure that code can still be emitted, just not cached.
Some(CacheInfo { | ||
local: Some(local), | ||
emit, | ||
map, | ||
// we no longer store the emit and map in their own files |
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.
this impacts the output of deno info mod.ts --json
, which is a breaking change. It feels like this is something we should address in deno_graph
or at least make a wider note of instead of sort of just stubbing it off.
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.
Yes, see the bottom of the PR description. It was agreed upon that breaking this was worth it in order to fix the issues.
That said, an alternative to not be breaking is to store a hash of the emit in addition to the source in the current version file. Then we would load the source, versions (two hashes), and emit then check that the emit hash matches the one in versions and the source hash matches the one in versions. If they do, then we can use the emit. By breaking here the main gain we get is that we don't need to bother hashing the emit... the more I think about it the more I would prefer this instead actually and it would be less work, though still breaking for deno_cache (because of change to versions file). Thoughts?
Edit: Oh, there is also the source map hash. That could just be moved back into the file.
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.
It would be really easy to pivot this PR to that actually. I think I will try it out on Monday and see how it performs. I'm getting a little concerned depending on sqlite so much.
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 got a bit carried away and opened this PR that does this: #15220 -- I think it's better
use test_util::TempDir; | ||
|
||
#[test] | ||
fn info_with_compiled_source() { |
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.
Why just remove the test... This is an strong indication that we are introducing a breaking change with deno info
, something we should address.
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.
Yes, it was removed because of the breaking change (address in PR description). This is testing if "emit: " is in the output on line 35 and that's no longer the case.
Closing this in favour of #15220 as it's less breaking. Measured the performance of everything and both this and that PR have the same performance (about 15% faster than main on the test I was doing) |
This change causes source files to be emitted on demand (emits should no longer get out of sync with sources except potentially with
deno coverage
), stores the emit cache in an sqlite database, and no longer stores the source maps inline in the emitted file (it only embeds source maps on the fly in a file if someone uses--inspect
or--inspect-brk
).Test for TS file changing between running workers (should now work)Edit: nope it doesn't because it gets the source from the cached module graph, which seems reasonable. Will have to look into this later.Closes #13302
Closes #15124
Breaking Change
The emit file is no longer included with
deno info --json
.