You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello. First, thanks for this outstanding tool, I find it one of the best out there for comparing complex objects.
Now the issue(specific for v.0.10 and 0.11):
the sameBeanAs matcher takes VERY long time to execute. In some cases it took like 1-2 seconds for me (which is slow) but I was ready to bear with it in exchange for nice error messages and ability to ignore fields, but today I found a single operation take 20 seconds (!!!).
The setup I use: Groovy language, Spock framework, shazam version 0.11
See screenshot:
How I did that measuring: basically just
What I compare: just couple custom domain classes that represent jsons, not too heavy (not heavy at all, I would say rather simple)
Important notes: The 20 second issue reproduces in avg once per ~4 runs, not always, but even when it is not 20s, it takes about 1-2 seconds which is very slow too.
The issue is not reproducing in shazam v0.9 (which I rolled back too), all the operations take <10 milliseconds in absolutely equal conditions.
I would be looking into your source code when I have some free time, but it would be great if someone have some thoughts on this and could do that quicker. This issue may be a major showstopper for attracting wider auditory to this tool so I'm really concerned about getting this fixed ASAP.
The text was updated successfully, but these errors were encountered:
Hello, thanks for your message.
Could you provide a code snippet that reproduces the issue?
That would help greatly trying to identify the problem.
Thanks
Ok I have something.
First of all, it appeared to be a groovy-only case. Previously I thought that this is a more general issue. Issue appears when you add any method to ANY class using Groovy's metaClass.
So this works perfect:
package example.spec
import example.Name
import spock.lang.*
import static com.shazam.shazamcrest.matcher.Matchers.*
import static spock.util.matcher.HamcrestSupport.*
class MySpec extends Specification {
@Unroll
def "example test"() {
given:
def actual = new Name(first: "foo", last: "bar")
def expected = new Name(first: "foo", last: "bar")
expect:
def now = System.currentTimeMillis()
that actual, sameBeanAs(expected)
println("sameBeanAs took: ${System.currentTimeMillis() - now}millis")
where: iterations << (1..3)
}
}
But now add this code right after 'given' and before 'def actual'(it actually doesn't matter where to use metaclass, it can even be not in the test class but somewhere else):
Map.metaClass.anyNewMethod = { /*do anything, it doesn't matter*/ }
And now the execution time bumps up to 3-20 seconds per each assertion. It doesn't have to be Map, it can basically be any class (String, Integer etc.), doesn't matter.
In debug I see that the amount of 'circularReferenceTypes' is doubled when metaclass is used.
So this issue messes up with Groovy language a lot.
Hello. First, thanks for this outstanding tool, I find it one of the best out there for comparing complex objects.
Now the issue(specific for v.0.10 and 0.11):
the sameBeanAs matcher takes VERY long time to execute. In some cases it took like 1-2 seconds for me (which is slow) but I was ready to bear with it in exchange for nice error messages and ability to ignore fields, but today I found a single operation take 20 seconds (!!!).
The setup I use: Groovy language, Spock framework, shazam version 0.11
See screenshot:
How I did that measuring: basically just
What I compare: just couple custom domain classes that represent jsons, not too heavy (not heavy at all, I would say rather simple)
Important notes: The 20 second issue reproduces in avg once per ~4 runs, not always, but even when it is not 20s, it takes about 1-2 seconds which is very slow too.
The issue is not reproducing in shazam v0.9 (which I rolled back too), all the operations take <10 milliseconds in absolutely equal conditions.
I would be looking into your source code when I have some free time, but it would be great if someone have some thoughts on this and could do that quicker. This issue may be a major showstopper for attracting wider auditory to this tool so I'm really concerned about getting this fixed ASAP.
The text was updated successfully, but these errors were encountered: