Skip to content
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

STOP GENERATING THOUSANDS OF MODULES!!! #10755

Open
edescourtis opened this issue Feb 19, 2023 · 7 comments
Open

STOP GENERATING THOUSANDS OF MODULES!!! #10755

edescourtis opened this issue Feb 19, 2023 · 7 comments
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@edescourtis
Copy link

edescourtis commented Feb 19, 2023

I know the use of meta-programming is fun. But the BEAM doesn't handle loading thousands of modules very well. We have several Google libraries in our deployment Elixir and just loading Google API libraries takes over a minute!!! OVER A MINUTE for a few APIs!!!!

iex -S mix run --no-start
fn ->
  times =
    Application.loaded_applications()
    |> Enum.map(fn {app, _desc, _vsn} ->
      modules = Application.spec(app, :modules)
      {time, _result} = :timer.tc(fn -> Enum.each(modules, &Code.ensure_loaded!/1) end)
      {app, System.convert_time_unit(time, :microsecond, :millisecond)}
    end)
    |> Enum.sort_by(&elem(&1, 1), :asc)

  Enum.each(times, &IO.inspect/1)
  times |> Enum.map(&elem(&1, 1)) |> Enum.sum() |> IO.inspect()
end.()
# {application, time_in_ms}
...
{:google_api_you_tube, 6336}
{:google_api_dfa_reporting, 11710}
{:google_api_vision, 15091}
{:google_api_content, 29394}
@edescourtis edescourtis added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Feb 19, 2023
@lpgauth
Copy link

lpgauth commented Jun 7, 2023

Is there a plan to fix this? I'm thinking I'm just going to vendor the modules I need instead of including the full library but it feels dirty.

@lpil
Copy link

lpil commented Oct 25, 2023

I ended up ditching this library in favour of directly working with the API I needed, it worked much better.

@lawik
Copy link

lawik commented Oct 30, 2023

I experimented with this. Kind of a thought-stream as I went. But not generating a module per Model/schema seems like good bang for the buck: https://fosstodon.org/@lawik/111306047662675335

(github branch ref for ease: https://github.com/lawik/elixir-google-api/tree/lightweight-generator)

Instead of modules and structs it will generate a bunch of functions and it will provide typespecs for the non-struct maps. So you still get t docs in iex and can know what type goes where.

For a fairly small API with a bunch of Models (Chat API V1) it went from 101 modules to 5.

@petermueller
Copy link

I've just always brought in only the sub-repos necessary (e.g. google_api_storage only results in GoogleApi.Gax and GoogleApi.Storage), or is there a cost I'm not noticing?

I can definitely see not wanting "everything" if you're pulling in the "root" repo though. That could be annoying. This whole repo at large feels abandoned though.

@lawik
Copy link

lawik commented Dec 8, 2023

If I generate just the AiPlatform endpoints of Google which would be one of these deps. That is about a thousand modules in schemas/models. Most of which I don't use or need. Thousand modules takes a bit to compile.

@petermueller
Copy link

Ah dang, that stinks

@tsloughter
Copy link

If mix doesn't support explicitly include/excluding modules it probably should and would be a good feature to suggest in its issues.

This made me realize we should have include support in rebar3/relx :). reltool supports explicit include but in rebar3/relx we only support exclude which probably isn't good enough in this situation since you'd have to list so many.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

6 participants