Slow GeoShapeQuery Performance in Bleve (v2.4.3) #2114
-
I'm experiencing slow performance with Bleve's GeoShapeQuery in my Go (v1.22) application. The query takes around 355 ms to return 51,092 hits, and I'm hoping to optimize it for faster results and understand why my code is running slow. I'm using the following code to create the GeoShapeQuery:
I varied the batch size used to build the index then searched with one of the polygons:
I non-randomly varied the number of entries (batch > 100):
I varied the size of the polygon (batch > 100):
Setting the relation to “within” is faster than using “intersects”. I'd appreciate any guidance on optimizing my GeoShapeQuery performance. Are there any potential issues with my code or configuration that could be causing the slow results? I've created a complete minimal example on github: |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Hey @Likith101 would you look into this one when you can please. |
Beta Was this translation helpful? Give feedback.
-
Hey @MeonAigeanta , apologies for the late response. I went through your code and I only find one thing that could help improve your performance and that is multithreading the queries. For a use case with one query at a time however, this is the maximum as of now. There are a few work in progress commits to improve performance in this area as of now. You could perhaps try cherry picking this (blevesearch/zapx#258) commit on a local bleve/zapx build and run the performance numbers again. |
Beta Was this translation helpful? Give feedback.
Hey @MeonAigeanta , apologies for the late response.
I went through your code and I only find one thing that could help improve your performance and that is multithreading the queries. For a use case with one query at a time however, this is the maximum as of now.
There are a few work in progress commits to improve performance in this area as of now. You could perhaps try cherry picking this (blevesearch/zapx#258) commit on a local bleve/zapx build and run the performance numbers again.