Slow application start time relative to other dependencies

[vanderhoop]

Elixir 1.18.4
Erlang 27.3.3
makeup_syntact 0.1.3

Macbook OS 15.6.1
M4 Pro (14 CPU Cores, 20 GPU Cores, 24gb memory)

Hi! I dug into the application start times of the sub applications in my phoenix app, and found that makeup_syntact is taking up the vast, vast majority of the application start time.

dbg output of application start times in a phoenix app (included to show start times relative to other deps)

Enum.sort(dep_start_times_in_ms, :desc) #=> [
  {326.671, :makeup_syntect},
  {67.183, :rum_dash},
  {13.13, :tidewave},
  {6.382, :req},
  {5.59, :honeybadger},
  {5.006, :hackney},
  {4.319, :phoenix_live_reload},
  {4.133, :live_admin},
  {4.02, :yamerl},
  {3.855, :plug},
  {3.38, :phoenix},
  {2.718, :runtime_tools},
  {1.979, :phoenix_live_dashboard},
  {1.934, :swoosh},
  {1.715, :nimble_pool},
  {1.537, :postgrex},
  {1.493, :memoize},
  {1.476, :telemetry},
  {1.467, :telemetry_poller},
  {1.231, :phoenix_pubsub}
]

I thought this was due to the registering of too many lexers, but even when explicitly scoped to a single lexer via config :makeup_syntect, register_for_languages: ["html"], the problem persists.

I've traced the problem down to the following call in MakeupSyntect.Application.start/2:

:timer.tc(fn ->
  MakeupSyntect.initialize_default_syntax_set()
end)
|> dbg()

#=> {319703, :ok}

The above function is called prior to language registration. It strikes me that the configured/requested languages should be considered before initializing the entire default syntax set, as there's a good chance many of the syntaxes can safely be ignored.

[vanderhoop]

Did a bit more debugging, and the slowdown appears to be in the NIF/rust code for initialize_syntaxes_from_folders.

FWIW, the call to MakeupSyntect.initialize_default_syntax_set() was added in 82c44e8, seemingly to support some HEEX templating considerations, but I wonder if that behavior should be opt-in, as many applications don't need to support heex highlighting.

[SteffenDE]

makeup_syntect is primarily meant for compile-time usage, such as with ex_doc, so startup time was not a major consideration yet. Do you require it at runtime?

Previously, the syntaxes were loaded when first trying to highlight something, so the total time taken would still be the same, just at a different point in time.

[josevalim]

Perhaps a better option it's to allow explicit listing of the languages to be loaded and, in case a language is not listed, you will skip it altogether. Would that improve performance?

[SteffenDE]

Possibly, but I’m not sure if syntect provided a function to do that. Iirc it is very easy to load all included syntaxes, but not to only do a few, but I’m not at the PC to check right now. Will check tomorrow :)

For now, I recommend to use only: :dev or runtime: false on the dependency if you don’t need it at runtime.

[vanderhoop]

makeup_syntect is primarily meant for compile-time usage, such as with ex_doc, so startup time was not a major consideration yet. Do you require it at runtime?

We do require it at runtime. We syntax highlight dynamic html snippets that may also have non-empty <style> and <script> tags in their content. Moving to makeup_syntect provided highlighting for all of the code, where previously we had to jump through some hoops to get syntax highlighting for the HTML tags, but also the CSS and JavaScript code within the aforementioned tags.

Previously, the syntaxes were loaded when first trying to highlight something, so the total time taken would still be the same, just at a different point in time.

A displacement of the time spent (from compile-time to runtime) would make sense, however I tested this hypothesis by removing MakeupSyntect.initialize_default_syntax_set() outright, and a) it doesn't break any runtime behaviors for us (highlighting still works), b) significantly improves the application start time, and c) doesn't incur a runtime performance penalty (or if it does, it's nowhere near the 300ms seen in the application start time). I'm not sure why that would be, but I suspect it could be because the two_face rust library adds a bunch of extra syntaxes, but html, css, and js are already included in Syntect's bundled defaults, so maybe no additional loading occurs in my specific use case?