Project

Profile

Help

Bug #2763

closed

fn:key() - optimization not working

Added by Michael Kay almost 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Performance
Sprint/Milestone:
-
Start date:
2016-05-27
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.7
Fix Committed on Branch:
9.7, trunk
Fixed in Maintenance Release:
Platforms:

Description

In the implementation of the fn:key() function, the code is designed to optimize for the common case where the first argument is known statically. This optimization is not working, so the lexical QName is expanded and a key definition located from the key manager each time key() is called.

Actions #1

Updated by Michael Kay almost 8 years ago

I have implemented the basic changes to achieve this (on the 9.7 branch, not yet committed), and it is working - except for export.

The design uses a CurriedSystemFunction in the same way as similar optimizations for translate, format-number, etc. But the code for exporting and importing calls to a CurriedSystemFunction is very ad-hoc so I made changes here - the idea is to export the function call as if the optimization had not taken place, and then repeat the optimization on import. At present the XSLT3 type tests are crashing when run with -export.

The problem is in establishing correct bindings between components and I suspect the problem is that the "original function call" which we are exporting in place of the curried call includes subexpressions that have the wrong binding slot number.

Actions #2

Updated by Michael Kay almost 8 years ago

I think I have fixed these problems. A CurriedSystemFunction now has to provide a method to export itself as if it were the original function call. The package loader calls the same method (fixArguments()) as the optimizer to re-optimize the function call into its curried form.

Actions #3

Updated by Michael Kay almost 8 years ago

Having got this working, I have a feeling it might all be over-complex. The regex functions like matches() manage pre-evaluation of the regular expression without any of this complexity, simply by computing the redundant data during SystemFunction.makeFunctionCall().

Actions #4

Updated by Michael Kay almost 8 years ago

I've decided to follow a different approach. Rather than making key() use a CurriedSystemFunction (which is currently used by translate() and format-number()), I've scrapped CurriedSystemFunction (which creates a lot of complexity for stylesheet exporting) and these functions now optimize themselves simply by putting data in local fields within the SystemFunction object (an approach which works perfectly well for the regular expression functions).

At present this is giving some failures on XSLT format-number tests.

Actions #5

Updated by Michael Kay almost 8 years ago

Now seems to be working. There are a few test failures with -export but I don't think they are related. Not yet committed. Need to copy the changes to the 9.8 branch.

Actions #6

Updated by Michael Kay almost 8 years ago

  • Status changed from New to In Progress
  • Priority changed from Low to Normal
  • Applies to branch 9.8 added
  • Fix Committed on Branch 9.7 added

Changes now committed on the 9.7 branch. Changes applied to the 9.8 branch, but not yet committed because they interact with other changes in progress.

Actions #7

Updated by Michael Kay almost 8 years ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 9.8 added
Actions #8

Updated by O'Neil Delpratt almost 8 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.7.0.6 added

Bug fixed in maintenance release 9.7.0.6.

Actions #9

Updated by O'Neil Delpratt almost 7 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)
Actions #10

Updated by O'Neil Delpratt almost 7 years ago

  • Applies to branch deleted (9.8)

Please register to edit this issue

Also available in: Atom PDF