| Summary: | PATCH Patch for performance issues with DataFormatter Fractions | ||
|---|---|---|---|
| Product: | POI | Reporter: | Alan Davis <alan.davis.apache> |
| Component: | POI Overall | Assignee: | POI Developers List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alan.davis.apache, samuel.langlois |
| Priority: | P2 | ||
| Version: | 3.9-dev | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: |
Initail patch file to limit impact
Example xls that hangs POI |
||
Created attachment 29591 [details]
Example xls that hangs POI
|
Created attachment 29588 [details] Initail patch file to limit impact DataFormatter Fractions formats that use 4 digits ("# #/####) or more are VERY slow. 4 digits takes around 1 second to process, 5 digits 100 seconds and so on. To compound the issue: a) if there is a -ve format (N in the P;NZ;T format), the length of the N format is added to the digit count, resulting in a locked up CPU. For example "# #/#;# #/#" is taken to be the same as "# #/#######" (7 digits). b) Custom text is also counted. For example: "# #/#"Credits" is taken to be "# #/##########" The attached patch tries to limit the impact of the issue rather than fix the code that calculates the fraction: - It limits the number of digits to 4 (additional # chars are ignored) - It splits of the N part of the format (if it exists) from the P part - It ignores any custom text (appears not to be generally supported elsewhere) - Adds support for negative numbers - Fixes a bug in calculations of negative numbers - Adds a number of unit tests for fractions - When there are both P and N parts, a FractionFormat is only now used if both parts include #/# OR ?/?