[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

First experience using own baton

From: Oto BREZINA <otik_at_printflow.eu>
Date: Tue, 04 Sep 2012 13:05:00 +0200

I decided to try own baton implementation for file diff. Even I known
your opinion, I still think it is worthy to try.

Expected gain:
- remove need of temporary file handling
- speed increase (text is already divided into lines, no need to convert
to UTF8 (from UTF16), no need access file system) I expected double the
- implementation of our own normalizing rules (EOLS(all we support),
whitespaces, ....)
- possibly less memory consumption

I took diff_memory.c and tweak it to my needs, basically it means to use
tokens from CFileTextLines.

After I make it work (without normalizing for a moment) it runs a way
slower then diff_file solution. 1.3 to almost 2 times slower.
Do you have any idea why it that? My only guess is that baton code is
too far from diff code, so we have cache misses. Maybe some windows
protection while jumping to/from code boundary dll to main code?
I have no idea why it can be that slower. I use already vector as base
class as it is bit faster then deque on read.

I will try to use original codes for diff_file in main code to see if it
is implementation or some other issue.
I also think about to use modified diff_memory - remade for wchar_t as
we have whole file converted to UTF16 in memory in some load stages.

For a moment only one of four gain is made.

I found that you implemented SVNLineDiff.
What is your experience with it ?
Why did you implemented your own Adler32 methode?
Why you and svn guys start Adler32 with 0, when according to
http://en.wikipedia.org/wiki/Adler-32#The_algorithm A is initialized to
1? Shouldn't we start Adler32 with 1 as checksum?

Oto ot(ik) BREZINA - 오토
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-09-04 13:05:21 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.