[Nepomuk] Review Request: Virtuoso Backend: Optimize ODBC getCharData

[Vishesh Handa]

> On Sept. 17, 2012, 12:38 p.m., Sebastian Trueg wrote:
> > I suppose 100 is fine in most situations except for long literals which are rarely queried anyway.
> > This looks good. Did tests show that the overall performance improves on the getData call?

Yup. The Valgrind output showed it taking less time to execute, but this wasn't very scientific.

I even went through large parts of the ODBC documentation - We can optimize query result fetching quite a bit. But I want proper benchmarks before I do that. If you want I can wait to push this until I have some more concrete benckmarks.


- Vishesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106467/#review19063
-----------------------------------------------------------


On Sept. 17, 2012, 9:37 a.m., Vishesh Handa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106467/
> -----------------------------------------------------------
> 
> (Updated Sept. 17, 2012, 9:37 a.m.)
> 
> 
> Review request for Nepomuk, Soprano and Sebastian Trueg.
> 
> 
> Description
> -------
> 
>     Only use 1 SQLFetchData command in most of the cases.
>     
>     Callgrind stats show that 67.5% of the time in this function is spent in
>     the first SQLFetchData, and an additional 27% in the second SQLGetData.
>     We can avoid some of this extra cost, by only calling the function
>     once.
> 
> I can change the size of the default buffer if required.
> 
> 
> Diffs
> -----
> 
>   backends/virtuoso/odbcqueryresult.cpp a4f2387 
> 
> Diff: http://git.reviewboard.kde.org/r/106467/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120917/e31effda/attachment.html>