Quantcast

About rule caching

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

About rule caching

sulfinu
Hello,

I have a quick question on rule caching for rules that take parameters: when testing for already cached returned result, how do you compare parameter values? With ".equals()" or with "==" ?
Thanks.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About rule caching

mathias
Administrator
I'm not quite sure I get what you want to know?
Can you provide some more details or maybe even an example?

Cheers,
Mathias

---
[hidden email]
http://www.parboiled.org

On 22.07.2011, at 12:49, sulfinu [via parboiled users] wrote:

> Hello,
>
> I have a quick question on rule caching for rules that take parameters: when testing for already cached returned result, how do you compare parameter values? With ".equals()" or with "==" ?
> Thanks.
>
> If you reply to this email, your message will be added to the discussion below:
> http://users.parboiled.org/About-rule-caching-tp3191073p3191073.html
> To start a new topic under parboiled users, email [hidden email]
> To unsubscribe from parboiled users, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About rule caching

sulfinu
All right. Say I defined a rule as follows:

@Cached
Rule X_ELEMENT(XEnum type, boolean flag)
{
... // the code
}

What is the mechanism used for caching the result returned be X_ELEMENT()? You say (in the docs) that Parboiled extension code verifies whether this method has already been called with the same parameters, and if so, the result retained back then will be returned for the current invocation. I'm asking what exactly is understood by "the same parameters":
 - the same as in equals()?
 - the same as in ==?
Testing for parameter identity is faster, and in my particular example is the same as testing for equality.

For example, if you're using a HashMap for memorizing previous results of X_ELEMENT(), then you're using the equals() test.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About rule caching

mathias
Administrator
Ok, I see what you mean now.
The documentation should probably be a bit more specific in this regard.

The piece of code that is responsible for this is the "CachingGenerator": https://github.com/sirthias/parboiled/blob/master/parboiled-java/src/main/java/org/parboiled/transform/CachingGenerator.java

In the case of your example Rule method the caching structure used is indeed a HashMap.
The arguments to your rule method should therefore have proper "hashCode" and "equals" implementations in order to work as expected.

Cheers,
Mathias

---
[hidden email]
http://www.parboiled.org

On 25.07.2011, at 09:35, sulfinu [via parboiled users] wrote:

> All right. Say I defined a rule as follows:
> @Cached
> Rule X_ELEMENT(XEnum type, boolean flag)
> {
> ... // the code
> }
> What is the mechanism used for caching the result returned be X_ELEMENT()? You say (in the docs) that Parboiled extension code verifies if this method has already been called with the same parameters, and if so, the result retained back then will be returned for the current invocation. I'm asking what exactly is understood by "the same parameters":
> - the same as in equals()?
> - the same as in ==?
> Testing for parameter identity is faster, and in my particular example is the same as testing for equality.
>
> For example, if you're using a HashMap for memorizing previous results of X_ELEMENT(), then you're using the equals() test.
>
> If you reply to this email, your message will be added to the discussion below:
> http://users.parboiled.org/About-rule-caching-tp3191073p3196782.html
> To start a new topic under parboiled users, email [hidden email]
> To unsubscribe from parboiled users, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About rule caching

sulfinu
Thanks for the quick reply.
I can't help saying that a parameter identity check would be faster and also _appropriate_ since it is expected that rule producing methods are called only by other rules of the same parser extending BaseParser.
If rules taking parameters are an "internal affair" (i.e. internal implementation details of the parser), then no programmer would employ "equal" parameters when calling them, but identical parameters, actually.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About rule caching

mathias
Administrator
You may be right in saying that reference equality would in most cases do the trick as well.
However, since the effect of rule tree creating performance (rather than the rule _execution_ performance) is negligible in all but a very selected few cases it's an optimization that's not generally worthwhile...

Cheers,
Mathias

---
[hidden email]
http://www.parboiled.org

On 25.07.2011, at 12:09, sulfinu [via parboiled users] wrote:

> Thanks for the quick reply.
> I can't help saying that a parameter identity check would be faster and also _appropriate_ since it is expected that rule producing methods are called only by other rules of the same parser extending BaseParser.
> If rules taking parameters are an "internal affair" (i.e. internal implementation details of the parser), then no programmer would employ "equal" parameters when calling them, but identical parameters, actually.
>
> If you reply to this email, your message will be added to the discussion below:
> http://users.parboiled.org/About-rule-caching-tp3191073p3197054.html
> To start a new topic under parboiled users, email [hidden email]
> To unsubscribe from parboiled users, click here.

Loading...