I vaguely remember that Gunnar had left some issues back in the day for some ideas on SPARQL optimizations (e.g., a "most constrained first heuristic"), so it might be worth digging those up before jumping into anything else... IIRC the original code was more tailored towards simplicity and correctness than speed.
Be warned, that parsing and turning the results into an algebra that is then executed causes a lot of indirections, making the SPARQL part quite difficult to debug (and hence probably to pofile)... I remember that it's easy to get lost in there for hours, especially if you don't understand the big picture of that code... So sure, profiling the code is always a good idea, but maybe don't start with the test cases that get us close to (or above) the stack depth limit anyhow ^^ j On Monday, November 2, 2020 at 12:22:05 PM UTC+1 nichol...@surroundaustralia.com wrote: > I think tests against benchmarking datasets like LUBM should be done > secondarily. Firstly I think general Python timing testing like Wes > mentioned should be carried out. This is because I suspect the speed issues > might be to do with whole chunks of Python code executing even before the > actual SPARQL execution (perhaps the query parsing rather than execution > etc.) but this needs to be established and that's what I think is needed > initially. After that, then LUDM indeed: we need to know how RDFlib > compares to triplestores etc. > > I will try and look into using a tool like SnakeVis. > > Thanks for the tips! > > On Sun, Nov 1, 2020 at 6:31 AM Boris Pelakh <pel...@gmail.com> wrote: > >> I don't have that much experience with Python profiling, but can take a >> shot at getting some measurements. Is there a particular benchmark (LUBM? >> BSBM) that would make a good starting point? >> >> On Sat, Oct 31, 2020 at 2:32 AM Nicholas Car < >> nichol...@surroundaustralia.com> wrote: >> >>> Hi all, >>> >>> The slowness of executing a SPARQL query against an RDFlib Graph annoys >>> me so I often use loops over them instead, but this leads to, sometimes, >>> verbose Python programming that's not translatable to triplestores with >>> SPARQL interfaces and other programming languages etc. >>> >>> I would love to see RDFlibs' graph.query function sped up so I could >>> just use SPARQL queries! >>> >>> Is anyone else on this list interested in this and do you have >>> experience profiling Python to find out where the slowness occurs? If we >>> knew where the slowness occurs, we might be able to find a way to speed >>> things up. >>> >>> Thanks, >>> >>> Nick >>> >>> -- >>> >>> >>> ______________________________________________________________________________________ >>> kind regards >>> *Dr Nicholas Car* >>> Data Systems Architect at SURROUND Australia Pty Ltd >>> Address P.O. Box 86, Mawson, Canberra ACT 2607 >>> Phone +61 477 560 177 <++61+477+560+177> >>> Email nichol...@surroundaustralia.comWebsite >>> https://www.surroundaustralia.com >>> >>> *Enhancing Intelligence Within Organisations* >>> *delivering evidence that connects decisions to outcomes* >>> >>> >>> [image: Australian-National-University-Logo-1 – ANU Centre for Water and >>> Landscape Dynamics] >>> >>> *Dr Nicholas Car* >>> Adj. Senior Lecturer >>> >>> Research School of Computer Science >>> >>> The Australian National University >>> Canberra ACT Australia >>> >>> >>> >>> https://orcid.org/0000-0002-8742-7730 >>> >>> https://cs.anu.edu.au/people/nicholas-car >>> >>> -- >>> http://github.com/RDFLib >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "rdflib-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rdflib-dev+...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rdflib-dev/CAP7nqh0RcyZXDScSpB8a2LgkYiRd2YHCbLrodoqbtHL2XiCyYg%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/rdflib-dev/CAP7nqh0RcyZXDScSpB8a2LgkYiRd2YHCbLrodoqbtHL2XiCyYg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> http://github.com/RDFLib >> --- >> You received this message because you are subscribed to the Google Groups >> "rdflib-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rdflib-dev+...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/rdflib-dev/CAMNphso68NrP0Oc_biz87Md%2Bph6--xnRTdnJtyp_E1%3D68dGc2Q%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/rdflib-dev/CAMNphso68NrP0Oc_biz87Md%2Bph6--xnRTdnJtyp_E1%3D68dGc2Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > > ______________________________________________________________________________________ > kind regards > *Dr Nicholas Car* > Data Systems Architect at SURROUND Australia Pty Ltd > Address P.O. Box 86, Mawson, Canberra ACT 2607 > Phone +61 477 560 177 <++61+477+560+177> > Email nichol...@surroundaustralia.comWebsite > https://www.surroundaustralia.com > > *Enhancing Intelligence Within Organisations* > *delivering evidence that connects decisions to outcomes* > > > [image: Australian-National-University-Logo-1 – ANU Centre for Water and > Landscape Dynamics] > > *Dr Nicholas Car* > Adj. Senior Lecturer > > Research School of Computer Science > > The Australian National University > Canberra ACT Australia > > > > https://orcid.org/0000-0002-8742-7730 > > https://cs.anu.edu.au/people/nicholas-car > -- http://github.com/RDFLib --- You received this message because you are subscribed to the Google Groups "rdflib-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/ea19a5d7-ad02-441f-85ed-b8e53397c7f6n%40googlegroups.com.
