Surface Boxicon - a component library that wraps the boxicons library (My first library :))

Very nice and congrats! Just a small thing but it sticks out immediately: could you give the background of the search area a softer white/grey colour so the contrast isn’t as overwhelming?

I’m sorry, I’m not following you. What search area are you talking about?

Sorry, I thought you were also behind the boxicons.com page. I meant the search area on that page.

Hi @fceruti. Nice work!

One thing to keep in mind is that defining modules is more expensive than defining multiple function clauses so since all components have the same props, I believe you would have a more consistent API, along with faster compilation, if you define a single component with name and maybe also a type prop to differentiate each icon. Something like:

def render(%{name: "video-plus", type="solid"} = assigns) do
  ~F[<svg ... width={@size} height={@size} class={@class} .../></svg>]
end

def render(%{name: "video-plus", type="regular"} = assigns) do
  ~F[<svg ... width={@size} height={@size} class={@class} .../></svg>]
end

def render(%{name: "bell", type="solid"} = assigns) do
  ~F[<svg ... width={@size} height={@size} class={@class} .../></svg>]
end

def render(%{name: "bell", type="regular"} = assigns) do
  ~F[<svg ... width={@size} height={@size} class={@class} .../></svg>]
end
...

Then you could use it like:

<BoxIcon name="bell" type="solid"/>

That’s great! Actually compilation time was something bothering me. Thanks!

Turns out, with this approach, compilation times went bananas! I’m compiling that single module in about 60 seconds, while it used to take around 10-15 seconds to compile all the 1500 modules.

I do appreciate how the API is much better now thou.

Anyone got any ideas on how to improve things? The file in question is this: surface-boxicon/lib/boxicon.ex at main · fceruti/surface-boxicon · GitHub

Large numbers of function clauses does eventually create exponentially slower compilation times. I have a similar issue in ex_CLDR and I know the gettext team went with splitting into modules as an option for the same reason.

I haven’t dug far enough to know where performance gets pathologically bad but ‘hundreds’ of clauses seems to exhibit this behaviour.

Is it because the 1500 modules are compiled in parallel, whereas the one giant module can only be compiled in one thread?
Can you compare the CPU time. I am curious whether too many function clauses have non linear performance penalty, on top of the lack of parallelization?

I’m not sure, but it makes perfect sense, since I saw a ~6X increase in time and I’m running on a 6 core machine.

How can I get the CPU time used in compilation?

use time(1). such as:

derek@roastidious:~/projects/roastidious$ time mix compile
Compiling 39 files (.ex)
Generated roastidious app

real	0m2.150s
user	0m3.608s
sys	0m1.017s

real is the wall time, user+sys is the cpu time spent; please note cpu time is usually larger than wall time.