Details
-
Type:
Enhancement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Completed
-
Affects Version/s: Release 1.3
-
Fix Version/s: Release 1.3
-
Component/s: None
-
Labels:None
-
Patch:Code
-
Approval:Ok
Description
Currently, the min and max functions are quite slow, since they don't take advantage of new primitive math.
Implement them in the same manner in which other primitive math functions are implemented for efficiency.
Attachments
Activity
Luke VanderHart
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | fast_min_max.patch [ 10210 ] | |
| Attachment | fast_min_max_no_contagion.patch [ 10211 ] | |
| Approval | Test | |
| Patch | Code |
Stuart Halloway
made changes -
| Attachment | 0784-min-max-take-3.patch [ 10217 ] | |
| Approval | Test | Screened |
Rich Hickey
made changes -
| Approval | Screened | Ok |
Christopher Redinger
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Completed [ 1 ] |
Stuart Halloway
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
This patch creates inline versions of min and max, combined with overloaded implementations in c.l.Numbers. It is over an order of magnitude faster using a test like this one (from 19 seconds to 1.2 seconds on my machine):
(time (loop [a 0 b 10 c 5] (if (< a 1000000000) (recur (inc a) (min b c) (max c b)))))There are two patches. One is contagious, but returns primitives for (long, double) input. The other is not contagious and returns primitives only for (long,long) and (double,double) args, but is still substantially faster than the original version.
(time (loop [a 0 b 10 c 5] (if (< a 1000000000) (recur (inc a) (min b c) (max c b)))))