Looks like I should update my local JDK anyway, it's out of date, I'll see what that says Monday.
As for asking the conditional rules what cells they cover, and then only checking those cells, that may be faster. I tried to have it fail fast if the cell in question is not in a range covered by a rule, but perhaps there is more to it than that. I've seen some interesting performance things pop up when digging into POI execution timing in the past, wouldn't surprise me to find out there is room for optimization somewhere in this part too. On Fri, Jan 5, 2018 at 8:29 PM Blake Watson <blake.wat...@pnmac.com> wrote: > For completeness purposes, I should say that the language level in IntelliJ > is 8. The JDK in use is 1.8.0_131 which I believe is the official Oracle > release. > > And this is line being objected to: > > return op != null && op.isValid(val, comp, (Comparable)null); > > > On Fri, Jan 5, 2018 at 8:05 PM, Blake Watson <blake.wat...@pnmac.com> > wrote: > > > On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey <greg.wool...@gmail.com> > > wrote: > > > >> for getRules() you can just create your own subclass and override it > with > >> a > >> public version that returns super.getRules() > >> > > > > That is precisely what I did, yes. And then I hit the matches thing. > > > > for matches, I don't see a quick easy way to override. What rule > > > >> definition seems to be slow, and what range does it cover? There are > >> definitely some formulas that take longer to evaluate than others - > >> especially things that do lookups or evaluate over an entire column > range. > >> Could be something else as well. > >> > > > > Well, I don't know. I'm not working in Java so I was trying to bring as > > much as possible into Clojure (in which I am working, to state the > > implicitly obvious). > > > > > >> Right now there is no easy way to shortcut the logic for a range when > the > >> formula is static (has no references relative to the specific range cell > >> being evaluated, meaning the formula has the same result independent of > >> "current" range cell). That kind of optimization hasn't even been > >> discussed yet, and reliably guaranteeing the code wouldn't miss a case > is > >> probably non-trivial. Might even make it more expensive than it's worth > >> unless the range is large and has a large number of non-empty cells. > >> Patches welcome, of course ;D > > > > > > If I had a set up with profiler working in Java and moved the Clojure > > code into Java I could maybe work out the precise problem but I'm kind > of > > under the gun on this one. I =am= working on getting a good Java set up > and > > burnishing my Java skills because I do want to contribute back to POI. > That > > said, this probably isn't the issue. > > > > I came up with an alternate plan which I had temporarily forgotten in > > trying to get all this other stuff to work: Instead of asking each cell > > what conditionals apply, asking the sheet about all the conditionals that > > apply and getting back a list of those conditionals with the cells > > affected . I'm guessing that would be (could be?) a lot faster. > > > > ===Blake=== > > > > > > > -- > > *Blake Watson* > > *PNMAC* > Application Development Manager > 5898 Condor Drive > Moorpark, CA 93021 > (805) 330.4911 x7742 <(805)%20330-4911> > blake.wat...@pnmac.com > www.PennyMacUSA.com <http://www.pennymacusa.com/> >
