# SnoopCompile 1.0 and 1.1

**URL:** <https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453>\
**Category:** Package Announcements\
**Created:** [November 24, 2019, 5:48pm UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453 "2019-11-24T17:48:07Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [November 24, 2019, 5:48pm UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/1 "2019-11-24T17:48:07Z")

</div>

I’m pleased to announce the 1.0 release of [SnoopCompile](https://github.com/timholy/SnoopCompile.jl), a package that can be used to diagnose and sometimes reduce package startup latencies (a.k.a., “time to first plot”).

Version 1.0 brings a couple of new features:

- the ability to “automate” precompile-file generation via `@snoopi`. This makes `@snoopi`, rather than the older `@snoopc`, the go-to tool of the package.
- better [documentation](https://timholy.github.io/SnoopCompile.jl/stable/). Among other things, the new documentation walks you through how to tell which precompile statements are “working” and which ones aren’t, allowing you to streamline your precompile files.

---

<div class="post-metadata">

**Author:** ![pablosanjose](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pablosanjose/32/7006_2.png) [@pablosanjose](https://discourse.julialang.org/u/pablosanjose)\
**Post date:** [November 24, 2019, 6:49pm UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/2 "2019-11-24T18:49:34Z")

</div>

Thanks Tim!

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [November 24, 2019, 7:48pm UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/3 "2019-11-24T19:48:14Z")

</div>

Does SnoopCompile filter out methods that depend on gensymmed names that might not be valid in other versions / builds of julia? In that case, is there any way to keep them,in case you are making your own sysimage for example ? (One of the major contributions to the improved startup in Julia 1.0 was due to changes in the build process that allowed keeping these gensymmed statements)

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [November 25, 2019, 12:45am UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/4 "2019-11-25T00:45:26Z")

</div>

`@snoopi` returns everything; it’s just `SnoopCompile.parcel` that’s implements filtering. [As you can see](https://github.com/timholy/SnoopCompile.jl/blob/78030b8e9fc94f16cfe13ce3f19e4287c24bf720/src/SnoopCompile.jl#L271-L299), for `@snoopi` the implementation of `parcel` is almost trivial, so we could easily tweak it if you think there are gains to be had.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [December 3, 2019, 5:08am UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/5 "2019-12-03T05:08:21Z")

</div>

What’s the support for keyword argument functions like?  
Using `@snoopi` created some statements like:

```julia
precompile(Tuple{PaddedMatrices.var"#mul_tn_quote##kw",NamedTuple{(:negative, :force_inline),Tuple{Bool,Bool}},typeof(PaddedMatrices.mul_tn_quote),Int64,Symbol,Int64,Type,Bool,Symbol,Symbol,Int64})

```

Which worked on the system/Julia version I called it with, but (obviously not) on Julia versions predating the `var_str` macro, but IIRC I got a function-not-defined error on a different Julia version as well.  
I’d have to double check tomorrow.

It reduced the compilation of a test function from 39 seconds to 37.5 seconds. I need to do a lot of work to get that better. Part of my problem is that I don’t have a real mental model for what takes time.  
Obviously generated functions don’t help, since both the generated function and the function that is generated need to get compiled.

I also had lots of statements like:

```julia
precompile(Tuple{PaddedMatrices.var"##s115#407",Any,Any,Any})

```

Which did not produce errors when tested locally. But, I’m not sure where exactly they come from, or how likely they’re to work across Julia versions/builds, so I commented all of these out.

Should parcel have filtered these names out?

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [December 3, 2019, 10:53am UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/6 "2019-12-03T10:53:54Z")

</div>

Anything that breaks across Julia versions is a bug, so please report it (with reproducer) as an issue in SnoopCompile.

> Obviously generated functions don’t help, since both the generated function and the function that is generated need to get compiled.

If you have essentially limitless type combinations, yes, it’s hopeless. But in limited cases it should work. Demo:

```julia
julia> @generated function mygen(x::T) where T
           Tbigger = T == Float32 ? Float64 : BigFloat
           :(convert($Tbigger, x))
       end
mygen (generic function with 1 method)

julia> using SnoopCompile

julia> tinf = @snoopi begin
           mygen(1.0f0)
           mygen(1.0)
       end
3-element Array{Tuple{Float64,Core.MethodInstance},1}:
 (0.00042700767517089844, MethodInstance for #s1#3(::Any, ::Any, ::Any))
 (0.0005278587341308594, MethodInstance for mygen(::Float64))           
 (0.003690004348754883, MethodInstance for mygen(::Float32))            

```

That `#s1#3` is the generator for `mygen`.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [December 3, 2019, 11:51am UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/7 "2019-12-03T11:51:20Z")

</div>

> [@tim.holy](#):
>
> Anything that breaks across Julia versions is a bug, so please report it (with reproducer) as an issue in SnoopCompile.

Does that include Julia-master?  
I just verified a case where `@snoopi` created on master (and working there) errors on 1.3.

```julia
ERROR: LoadError: UndefVarError: ##s41#17 not defined

```

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [December 3, 2019, 11:52am UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/8 "2019-12-03T11:52:04Z")

</div>

Absolutely. The precompile files need to work robustly across versions.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [December 10, 2019, 1:18pm UTC](https://discourse.julialang.org/t/snoopcompile-1-0-and-1-1/31453/9 "2019-12-10T13:18:30Z")

</div>

SnoopCompile 1.1 is out. It fixes a lot of the reported problems and adds a whole lot of additional robustness. In particular, this version looks up keyword methods in a manner that doesn’t depend on gensymmed names, particularly if you do the snooping on Julia 1.4+. (The `precompile.jl` file it writes should work on any Julia 0.7 or 1.x version.) It also discovers generators for `@generated` functions without relying on the gensymmed names. Only anonymous and inner functions rely on a gensymmed name.

There’s more information in the `NEWS.md`:

[https://github.com/timholy/SnoopCompile.jl/blob/master/NEWS.md](https://github.com/timholy/SnoopCompile.jl/blob/master/NEWS.md)