Opened 3 years ago

Closed 3 years ago

#2380 closed enhancement (wontfix)

Implement utility function clock.then()

Reported by: jogger Owned by:
Priority: minor Milestone: undecided
Component: router/general Version: 0.9.37
Keywords: Cc:
Parent Tickets: Sensitive: no

Description is an expensive call used very frequently within i2p and has been seen to impact performance especially on ARM. In most cases the precision it provides is unnecessary. I propose that sets a global tick value on each invocation that clock.then() simply returns.

All occurrences of that do not need subsecond precision could simply be changed to use the new function. Loss of precision should be neglectable, some ms max, much lower than the duration of a garbage collection that hits


Change History (6)

comment:1 Changed 3 years ago by Zlatin Balevsky

That's one way to attack the problem, although my preference is to find out all the usages of in tight loops and get rid of them.

comment:2 Changed 3 years ago by jogger

Hi zab, that will not work well as there are dozens of calls scattered along the way a message travels through the router.

For really quick & easy wins see isUnreachable und wasUnreachable in TransportImpl?.java or three completely useless calls in a row in PacketHandler?.java (see void run).

Due to my long test cycle I will start looking into this next week earliest (beginning with UDP packet pusher, the current bottleneck for 8 core ARM).

comment:3 Changed 3 years ago by zzz

You're both right. Removing dups is part one, then perhaps changing the architecture or making new methods - but we don't have nearly the info required to jump to OP's proposed solution.

What you might be missing is that we don't have any thread that does the clock slewing (unlike what you might see in some OS timekeeping thread). We rely on frequent calls to now() to implement the slewing.

Additionally, now() isn't that complex. What makes it slow on ARM, I don't know - perhaps the synchronization - which you may or may not be able to get rid of in your hypothetical then().

Also, there's not - that I can see - any objects created in now(), and in any case garbage collection is in a different thread, so I don't buy your theory about that slowing down now().

comment:4 Changed 3 years ago by jogger

RE GC: You got me wrong. Just a general remark that java timer values can always be impacted by GC before used or later compared and thus one should not strive for perfect precision.

RE ARM: now() is not slow on ARM, it is the massive number of invocations. And yes, there might be a better way to achieve the OPs goal (after the dups, see my previous comment for perfect candidates) and to take your remarks into account.

comment:5 Changed 3 years ago by jogger

OK, bad idea. Thought again, close this, I´ll have a much better one.

comment:6 Changed 3 years ago by zzz

Resolution: wontfix
Status: newclosed

closing at OP request, #2384 looks like the "better one".

Note: See TracTickets for help on using tickets.