I decided to try own baton implementation for file diff. Even I known
your opinion, I still think it is worthy to try.
- 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),
- 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