On 05/03/2011 23:27, John Beranek wrote:
> On 05/03/2011 23:23, John Beranek wrote:
>> Hi,
>>
>> I'm not sure if much performance comparison has been performed, but I'm
>> unhappy to report a significant _reduction_ in speed in a checkout.
A few other data points...
Import tests for this dataset:
On 05/03/2011 23:23, John Beranek wrote:
> Hi,
>
> I'm not sure if much performance comparison has been performed, but I'm
> unhappy to report a significant _reduction_ in speed in a checkout.
OK, here's an ra_local comparison:
Subversion 1.7 (r1078338) client, checking out from file:// (local d
Hi,
I'm not sure if much performance comparison has been performed, but I'm
unhappy to report a significant _reduction_ in speed in a checkout.
Subversion 1.7 (r1078338) client, checking out from localhost HTTP
server (Subversion 1.7 r1078338):
Checkout a tree with 3740 files, 121 directories, to
John Beranek wrote on Sat, Mar 05, 2011 at 21:56:22 +:
> On 05/03/2011 21:47, Daniel Shahaf wrote:
> > John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +:
> >> Results of "grep --before-context=10 "^FAIL:" tests.log":
> >
> > In case you aren't aware: after 'make check' has finished, yo
On 05/03/2011 21:47, Daniel Shahaf wrote:
> John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +:
>> Results of "grep --before-context=10 "^FAIL:" tests.log":
>
> In case you aren't aware: after 'make check' has finished, you can look
> at fails.log to see just the verbose test log only for f
John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +:
> Results of "grep --before-context=10 "^FAIL:" tests.log":
In case you aren't aware: after 'make check' has finished, you can look
at fails.log to see just the verbose test log only for failed tests.
[ pastebins may disappear someday, and aren't indexed by the list archives,
so... ]
John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +:
> On 05/03/2011 20:04, John Beranek wrote:
> > On 05/03/2011 18:33, Philip Martin wrote:
> >> Stefan Fuhrmann writes:
> >>
> >>> I suspect that -fstrict-
On 05/03/2011 20:04, John Beranek wrote:
> On 05/03/2011 18:33, Philip Martin wrote:
>> Stefan Fuhrmann writes:
>>
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
>>> r1078256 tries to circumvent that.
>>
>> John should be abl
On 05.03.2011 19:52, Stefan Fuhrmann wrote:
> On 05.03.2011 11:55, Branko Čibej wrote:
>> On 05.03.2011 11:34, Stefan Fuhrmann wrote:
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
>>> r1078256 tries to circumvent that.
>> Ahe
On 05/03/2011 20:04, John Beranek wrote:
> On 05/03/2011 18:33, Philip Martin wrote:
>> Stefan Fuhrmann writes:
>>
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
>>> r1078256 tries to circumvent that.
>>
>> John should be abl
On 05/03/2011 18:33, Philip Martin wrote:
> Stefan Fuhrmann writes:
>
>> I suspect that -fstrict-aliasing (or something similar)
>> might have broken svn_temp_deserializer__resolve().
>>
>> r1078256 tries to circumvent that.
>
> John should be able to confirm that by testing some revision less t
On 05.03.2011 11:55, Branko Čibej wrote:
On 05.03.2011 11:34, Stefan Fuhrmann wrote:
I suspect that -fstrict-aliasing (or something similar)
might have broken svn_temp_deserializer__resolve().
r1078256 tries to circumvent that.
Ahem. Type casting will not help, at least GCC's optimizer sees ri
Stefan Fuhrmann writes:
> I suspect that -fstrict-aliasing (or something similar)
> might have broken svn_temp_deserializer__resolve().
>
> r1078256 tries to circumvent that.
John should be able to confirm that by testing some revision less than
r1078256 using EXTRA_CFLAGS='-O2 -fno-strict-alias
On 28.02.2011 21:34, Daniel Shahaf wrote:
This is on-topic for dev@. We're aware of speed issues, but we'll
always appreciate more input.
I assume that meant I should send the message to dev? Here it is:-)
I did not find a bug filed on this specific case of slowness. Should I
file one?
Gunn
Greg Stein writes:
>> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
>> the POST request it defines the transaction name to be returned to the
>> client in the POST response. If the client recieves the new
>> SVN-VTxn-Name header it uses that name in the new URIs in the re
On 05.03.2011 11:34, Stefan Fuhrmann wrote:
> I suspect that -fstrict-aliasing (or something similar)
> might have broken svn_temp_deserializer__resolve().
>
> r1078256 tries to circumvent that.
Ahem. Type casting will not help, at least GCC's optimizer sees right
through them. The thing to do is
On 05.03.2011 01:56, Stefan Fuhrmann wrote:
On 05.03.2011 01:16, John Beranek wrote:
On 04/03/2011 23:02, Stefan Fuhrmann wrote:
On 04.03.2011 12:32, John Beranek wrote:
On 04/03/11 11:18, Philip Martin wrote:
John Beranek writes:
Oh, this is for a run of an installed copy of svnserve, as
17 matches
Mail list logo