clojurescript 2024-03-23

vraid22:03:27

Is it possible to limit or capture (in a variable) the execution time of an expression in clojurescript? I've got an expression that determines the resolution of some graphics, which is essentially (iterate f x), that could in theory go on indefinitely, but in practice the time taken by each iteration grows exponentially. When the page loads, i'd like to iterate as many times as possible, but stop at the first step taking more than 1-2 seconds. My shitty phone can only handle 6 steps for instance, while my computer can easily do 9, which is why i'd like it to load at a better resolution on more capable devices. Any ideas how i should approach this?

p-himik22:03:17

js/requestAnimationFrame

vraid22:03:15

Not sure this is the right approach, but i guess i could just get the current time before and after the call? :man-facepalming:

p-himik22:03:09

You sure can. That approach has one problem - the whole UI will be completely unresponsive (apart maybe from some scrolling - depends on the browser and its settings) until you're done. With js/requestAnimationFrame, you will at least give your user a chance to do something in the meantime.

vraid22:03:57

I can live with an unresponsive UI (for now), there isn't that much to do while waiting either way. But i'll bookmark js/requestAnimationFrame for when it does become an issue!

👍 1

vraid23:03:56

Now i have the issue that in

(let
 [a (.now js/Date)
  x (expensive-call)
  b (.now js/Date)])

a and b are identical. What am i missing, something about laziness?

vraid23:03:26

There is a loop in the call, that could be it

vraid23:03:25

Edit: it was a take. Added a doall which fixed it

jcoyle19:03:46

@U0552GV2X32 may be worth checking out the performance.now()https://developer.mozilla.org/en-US/docs/Web/API/Performance/now.

vraid20:03:20

That definitely seems more proper than Date.now. Searching a bit brought me this, which seems like a wrapper over both in case performance.now is unavailable https://cljs.github.io/api/cljs.core/system-time

p-himik20:03:58

Why would Date.now not be appropriate?

vraid20:03:49

It could lead to unexpected behaviour if you run it just as the clock switches to or from daylight saving's time

vraid20:03:32

"Also, Date.now() may have been impacted by system and user clock adjustments, clock skew, etc. as it is relative to the Unix epoch (1970-01-01T00:00:00Z) and dependent on the system clock. The performance.now() method on the other hand is relative to the timeOrigin property which is a https://w3c.github.io/hr-time/#dfn-monotonic-clock: its current time never decreases and isn't subject to adjustments."

p-himik20:03:38

Your question is about rendering, the order of magnitude is seconds. Tens of milliseconds at best when you're working with individual frames. > It could lead to unexpected behaviour if you run it just as the clock switches to or from daylight saving's time No. Date.now returns the epoch time, it's not affected by your tz or any other such thing.

p-himik20:03:06

"User clock adjustment" - yeah, but not daylight savings.

vraid20:03:10

Ah, right

vraid20:03:39

And i'm well aware that there's a miniscule risk of unexpected behaviour here, but there's also no cost in switching function

p-himik20:03:59

But it's a valid point. I imagine it's quite frustrating to receive a bug report where something hangs for an hour only because someone adjusted their clock right when your website was loading. :)

vraid20:03:08

Imagine the patience that user must have to not reload the page 😄

vraid20:03:59

Also, this specific use case is on the order of seconds, but it's good to know about this for future use

2024-03-23

Channels