Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow SpelCompiler to compile MapAccessor expressions [SPR-13638] #18215

Closed
spring-projects-issues opened this issue Nov 4, 2015 · 3 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Daniel Fernández opened SPR-13638 and commented

Thymeleaf 3.0 will modify the way in which SpEL expressions are executed inside templates.

One of the modifications will be that the context object (containing all the variables usable in expressions) will be passed to the SpEL evaluation engine wrapped as a Map, so that for most expressions (though not all), the use of custom PropertyAccessor will not be needed. And that's good because that's one of the conditions for the SpEL compiler to be able to run.

The problem is, a good amount of expressions in Thymeleaf templates look like:

${someobject.someproperty}

The "someproperty" part (which will internally use introspection on the "someobject" object) should be covered by the SpEL compiler... but the first part of the expression, "someobject", is obtained from a (wrapped) map. So in this case, given the expression includes the use of a non-introspection-based accessor, compilation is not performed at all.

It would be great therefore if the use of MapAccessor was included in the SpEL compiler capabilities, so that expressions as the one above could be compiled in Thymeleaf 3.0 templates (if the compiler is configured).

Of course, this would make expressions such as:

${someobject}

...which might be even more common, to be compilable too. But in such case no introspection is involved, so I doubt we would obtain any real performance gain. That's why I focus on two-level expressions.


Affects: 4.2.2

@spring-projects-issues
Copy link
Collaborator Author

Andy Clement commented

Implemented code generation for MapAccessor, it will now be compiled. Some basic numbers for a million iterations of various expressions.

  • expression is a simple key name "foo" and the root object is a map:
    Interpreted: 92ms Compiled: 15ms

  • expression is a key name and then a method invocation "foo.toUpperCase()" and the root object is a map:
    Interpreted: 568ms Compiled: 56ms

  • expression is a sequence of key names "foo.bar" and the root object is a map of maps:
    Interpreted: 297ms Compiled: 20ms

  • expression is a sequence of key names and then a method invocation "foo.bar.toUpperCase()" and the root object is a map of maps:
    Interpreted: 700ms Compiled: 60ms

@spring-projects-issues
Copy link
Collaborator Author

Daniel Fernández commented

That's awesome, thanks! I wasn't expecting such an improvement in Map-only expressions, but those figures look really good...

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Nice - to be rolled right into 4.2.4 then... Thanks, Andy!

Juergen

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 4.2.4 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants