> 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 > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
