Closed hkayabilisim closed 1 month ago
Update: I found a workaround: Setting intrusive_cancel=False seems to solve the issue: solara.use_thread(..., intrusive_cancel=False
.
cancel_guard
context around the function call seems the source of the slowness problem. @maartenbreddels do you have a recommendation for that? Is it an expected behavior?
Yes, when we tested this, it was tested with calls to pandas or vaex, which didn't have much overhead. We recently found out when we created use_task
and task
that indeed the overhead was larger than expected, and we therefore didn't enable it yet for task
and use_task
.
I think the docs should say instead:
WARNING: When intrusive_cancel=True, a tracer is installed into the thread, which will throw a special exception to cancel the thread. This gives a significant runtime overhead for running Python code (up to 20x)
What do you think?
Thank you for the explanation! Yes, I think adding this information to use_thread
doc will be helpful and enough. So, I'm not planning to investigate this issue any further because the workaround works just fine and I don't need "cancelling" option in near future.
Thank you again!
Problem A function runs very slow when it is run under
solara.use_thread
.How much slow: On my Mac, it is about 20 times. On Hugging Face (which uses Linux), 26 times slower.
How to reproduce: I deployed the code to https://huggingface.co/spaces/hkayabilisim/test_solara_use_thread for you to repeat the case. For demonstration, I used the prime checking code here: https://github.com/widgetti/solara/blob/master/solara/website/pages/api/use_thread.py To test the code, use large primes such as 160423, 203789, 364289, 991961, 1203793, 1667321, 3704053.
Screenshot