Re: Interested in making 'svn st' 10x faster?

2021-04-08 Thread Stefan Fuhrmann
On 06.04.21 21:14, Daniel Shahaf wrote: Stefan Fuhrmann wrote on Mon, Apr 05, 2021 at 21:17:23 +0200: +static svn_error_t *output_processed( + svn_task__t **task, + svn_cancel_func_t cancel_func, + void *cancel_baton, + apr_pool_t *result_pool, + apr_pool_t *scratch_pool) +{ +

Re: Interested in making 'svn st' 10x faster?

2021-04-07 Thread Nathan Hartman
On Wed, Apr 7, 2021 at 11:00 AM Stefan Fuhrmann wrote: > I attached the new patch. It is much cleaner, delivers good cold cache > performance (9x for large working copies) but with hot file caches, it > is still 3.5x slower than the "final product" (for very, very large w/c). The changes that I

Re: Interested in making 'svn st' 10x faster?

2021-04-07 Thread Stefan Fuhrmann
On 06.04.21 21:00, Stefan Fuhrmann wrote: On 06.04.21 08:12, Nathan Hartman wrote: > tasks-used-optimized-wc-status.patch applied with some offsets, so is against a slightly out-of-date trunk, but applied without conflicts. But my build had many test failures: Summary of test results:   

Re: Interested in making 'svn st' 10x faster?

2021-04-06 Thread Daniel Shahaf
Stefan Fuhrmann wrote on Mon, Apr 05, 2021 at 21:17:23 +0200: > +static svn_error_t *output_processed( > + svn_task__t **task, > + svn_cancel_func_t cancel_func, > + void *cancel_baton, > + apr_pool_t *result_pool, > + apr_pool_t *scratch_pool) > +{ > + svn_task__t *current = *task; > +

Re: Interested in making 'svn st' 10x faster?

2021-04-06 Thread Stefan Fuhrmann
On 06.04.21 08:12, Nathan Hartman wrote: On Mon, Apr 5, 2021 at 3:17 PM Stefan Fuhrmann wrote: See attachment (I may have used a somewhat outdated trunk). tasks-prepwork.patch refactors some utility code to make it reusable. tasks-main.patch is the new svn_task__t API, implementation and

Re: Interested in making 'svn st' 10x faster?

2021-04-06 Thread Daniel Shahaf
Stefan Fuhrmann wrote on Mon, Apr 05, 2021 at 21:17:23 +0200: > +++ status.c (working copy) > @@ -1123,15 +1288,15 @@ >if (depth == svn_depth_infinity >&& info->has_descendants /* is dir, or was dir and tc descendants > */) > { > - SVN_ERR(get_dir_status(wb,

Re: Interested in making 'svn st' 10x faster?

2021-04-06 Thread Nathan Hartman
On Mon, Apr 5, 2021 at 3:17 PM Stefan Fuhrmann wrote: > > See attachment (I may have used a somewhat outdated trunk). > > tasks-prepwork.patch refactors some utility code to make it reusable. > tasks-main.patch is the new svn_task__t API, implementation and bits of > testing. > tasks-used*.patch

Interested in making 'svn st' 10x faster?

2021-04-05 Thread Stefan Fuhrmann
On 05.04.21 20:19, Nathan Hartman wrote: On Mon, Apr 5, 2021 at 6:00 AM Stefan Fuhrmann > wrote: Hi all, Way back in 2014, I started work on an SVN equivalent to apr_thread_pool and came back to it recently.  The key features are output and callbacks

Re: Interested in making 'svn st' 10x faster?

2021-04-05 Thread Nathan Hartman
On Mon, Apr 5, 2021 at 6:00 AM Stefan Fuhrmann wrote: > Hi all, > > Way back in 2014, I started work on an SVN equivalent to apr_thread_pool > and came back to it recently. The key features are output and callbacks > happen in the same order as in sequential code, same for any svn_error_t >

Re: Interested in making 'svn st' 10x faster?

2021-04-05 Thread Daniel Shahaf
Stefan Fuhrmann wrote on Mon, 05 Apr 2021 10:00 +00:00: > Way back in 2014, I started work on an SVN equivalent to apr_thread_pool > and came back to it recently. The key features are output and callbacks > happen in the same order as in sequential code, same for any svn_error_t > raised, and a

Interested in making 'svn st' 10x faster?

2021-04-05 Thread Stefan Fuhrmann
Hi all, Way back in 2014, I started work on an SVN equivalent to apr_thread_pool and came back to it recently. The key features are output and callbacks happen in the same order as in sequential code, same for any svn_error_t raised, and a low-overhead single-threaded code path. Now, there is