authentic soft fennec friend brand fennecs

@softfennec

just, like, a creature

im fluffy

authentic soft fennec friend brand fennecs @softfennec1/19/2024, 6:06 PM

big fuckings to this dependency that i updated and it now has a processing thread for "better performance"

but naturally because this is python and i already need my own processing thread, over 97% of execution time in the main thread is now spent sleeping, waiting on that Better Performance processing thread to get some execution time. and so, a thing that previously took less than a second now takes 10 minutes. and i need to run that thing hundreds of times :')

the only upside is that i can use the previous version for now without anything breaking

You must log in to comment.

in reply to @softfennec's post:

echo wants to battle!@ysaie1/19/2024, 6:13 PM

oof, bold move for that dependency to add a non-optional thread in Python of all languages... yikes...

you've probably thought of this already, but is multiprocessing an option for your own worker thread to avoid the GIL?

authentic soft fennec friend brand fennecs @softfennec1/19/2024, 6:36 PM

yes, and i have a complicated and fragile contraption moving as much stuff to multiprocessing subprocesses as is at all feasible. another dependency library depends on there being a thread (that some of my code has to run in), though - and basically all the multiprocessing was done to avoid competing with that thread.

the best way to do this would honestly be to run the separate parts in their own processes entirely since they could just be running constantly in the background, but I'd have to rework just about everything to instead be some kind of facade that just receives data from a socket. so, perhaps understandably, i haven't done that yet

echo wants to battle!@ysaie1/19/2024, 7:27 PM

absolutely fair, parallelization is hard even without dealing with the IPC mess that separate processes brings in. im glad the problem library was downgradeable!

Pinned Tags

crow of the day