# Code generation vs literal unroll

**URL:** <https://numba.discourse.group/t/code-generation-vs-literal-unroll/301>\
**Category:** Community Support\
**Created:** [October 21, 2020, 12:43pm UTC](https://numba.discourse.group/t/code-generation-vs-literal-unroll/301 "2020-10-21T12:43:20Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![luk-f-a](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/luk-f-a/32/56_2.png) [@luk-f-a](https://numba.discourse.group/u/luk-f-a)\
**Post date:** [October 22, 2020, 9:57pm UTC](https://numba.discourse.group/t/code-generation-vs-literal-unroll/301/3 "2020-10-22T21:57:26Z")

</div>

> I can workaround the problem by banning revisiting nodes but that disable some valid cases for the pruner.

I think it would be fair to challenge whether such a large literal\_unroll is a targeted use case at all. I wouldn’t like to disable other valid cases to make room for my example. I just thought it’d be interesting to look at the comparison.

Again and again I find code gen the best option in many cases. Since you are more experienced, what’s your take on this? Is it better to improve things like `literal_unroll` until it can beat code gen, or is it better to speed up compilation of generated code? other people have also reported slow compilation times on large functions: [Tips or tricks for speeding up compilation time on first call of large Numba-jitted NumPy-containing functions?](https://numba.discourse.group/t/tips-or-tricks-for-speeding-up-compilation-time-on-first-call-of-large-numba-jitted-numpy-containing-functions/136)

---

_[View the full topic](https://numba.discourse.group/t/code-generation-vs-literal-unroll/301)._