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

[Sebastian Trueg]

> 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?
> 
> Vishesh Handa wrote:
>     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.
>     
>

Your call.


- Sebastian


-----------------------------------------------------------
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/4116e1b9/attachment.html>