I am giving a MLC a lot of inputs (one per item in the game in fact) and when (and only when) the MLC gui is open ML is using a ton of time. 66 ms, The inputs are constant and not changing but is ML constantly updating them for the gui? As soon as I close the gui time usage drops to 0.02 ms

Yup, it reads every single one of them from each wire on every single tick, then reads all outputs too, and re-creates all labels in the gui for each non-0 one.

Thinking is that it's fine, as:

• It's just when gui is open, so like why care about ups there.

• You probably don't want to miss changing inputs/outputs due to slow updates, as it can be confusing.
  Like, if gui is updated 1/40 ticks, and you happen to update your inputs/outputs every 20 ticks, you might never notice that they flip back-and-forth in-between gui updates.
  And this is especially worth it for lower game speeds, where you can actually notice things flapping around on ticks.

:( That makes sense. I probably should find a more efficient way than giving the MLC so many inputs anyway

Or guess it's no problem to just add an option for that and instead of
if next(global.guis) then update_signals_in_guis() end
use
if next(global.guis) and game.tick % conf.ticks_between_gui_updates == 0 then update_signals_in_guis() end

Added "GUI Signals Update Interval" startup setting in Mod Options (default = 1) to have less frequent GUI updates.
Env-vars window on the right is updated after each code run, so guess that one can be used to reliably see signal changes, even if they end up being synced with gui updates.

One unorthodox fix for this can be random intervals between gui updates, which would make whether you see some flapping there probabilistic, but almost guarantee it if you stare at the table for couple seconds. It'd probably be more confusing than useful though, so meh.