Thanks for the quick response.

1) It seems our bisecting is wrong. We manually moved commit by commit by
using "fossil checkout" command. Next time, we will use "fossil bisect"
command.
2) Sorry for the misleading. Our first report contains three queries. We
will submit another cases with correct bisect later.

Jinho Jung

On Mon, Apr 1, 2019 at 1:32 PM Richard Hipp <d...@sqlite.org> wrote:

> On 4/1/19, Jinho Jung <jinho...@usc.edu> wrote:
> > Hello,
> >
> > We are developing a tool called sqlfuzz for automatically finding
> > performance regressions in SQLite. sqlfuzz performs mutational fuzzing to
> > generate SQL queries that take more time to execute on the latest version
> > of SQLite compared to prior versions. We hope that these queries would
> help
> > further increase the utility of the regression test suite.
>
> Thanks for the report.
>
> Since there are already a bazillion fuzzers for SQLite, may I suggest
> that you choose a more a more specific and descriptive name for your
> fuzzer?  Perhaps "sql-perf-fuzz" or something similar - so that we
> know that your fuzzer is targeting performance regressions?
>
> >
> > We are sharing four SQL queries that exhibit regressions in this report.
> > Here’s an illustrative query:
>
> I only got 3 SQL queries.  What am I missing?
>
> Also, I got bisect results for all three problem that are different
> from the results you report.  When I run bisect, I get the same result
> for all three test cases:
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__sqlite.org_src_timeline-3Fbid-3Dy736b53f57fnbd49a8271dycb1511065dy6c6fb1c6eay30f08d5888y507c43537fy2c8769c69fn4371a0c46en4d0a949fd9n79c073878dy93386a7c97nd840e9bb02&d=DwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=Eb5d36HrPu-wBrtI5PLOoA&m=bTwdIvNq94lBWxZ0Jw0Hony2eN54rEUuJrZ2CNiSxYg&s=W8KSOERSMGlpnn6BItMu8zuy4oCZlGBlFUDrZGVwBzw&e=
>
> So it was apparently a bug-fix that caused the performance decrease.
> I have not looked into the details yet.  Perhaps there is an
> alternative fix for the bug that does not cause unnecessary
> performance loss.
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to