Closed brandonburkett closed 9 years ago
Seems your record have many edges, so unmarshalling the entire record could be very expensive. How many edges have the records? Let's say record #22:234, #22:266 and #22:235?
You are correct, we have lots of edges and this will be growing.
So I'm closing this issue. You discovered a best practice to keep memory lower ;-)
This consumes less memory in all cases? Can't it be like this by default?
@devourment77 Could you share your db so I can do some tests to understand if @vitorenesduarte is right about changing default behavior?
@lvca any progress here?
@vitorenesduarte I haven't received any response from @devourment77. I'd like to have a db where I can debug why there is so much difference
I've created a dummy database with this but the times of both queries are very alike so far.
I found a bug thanks to your code: the fetchplan fetches more than it should by loading many unnecessary records.
Do you mean with Java API?
I have queries that in console with fetchplan *:-2
take less time than with Java API.
I couldn't understand why.
Hope that the problem was this one you found.
The problem seems exactly this: no error but slowness because all not necessary loads. Fixing this in 2.0.8 and 2.1-rc2
Apologies for not getting back on this topic and thank you @vitorenesduarte and @lvca for looking into the issue further.
The problem was only in console: fetchplan :1 was used by default instead of :0.
Hello,
We have run into an odd performance issue with 2.0-SNAPSHOT with expand(). It seems that if you expand on an edge and include dot RID, it is much faster than if you do not. Oddly, both return the same data (whereas expand(out("edgeName").realProperty) only returns the realProperty field).
I am unsure if this is normal behavior or not, but we are seeing approx. 300ms performance difference.
Also, we are seeing some sizes of negative 1 (see "in_hasConcept" column). Note that Attractions have multiple concepts.