On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey <[email protected]> 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===
