Re: [Fwd: [Fwd: [Fwd: On ubuntu 8.04 it doesn't work well]]]

[Bartolomeo Nicolotti <bnicolotti siapcn it>]

Hi there,

I don't know if it can help or if it's even pertinent, anyway ....


for long strings in java the normal String class is really slow, because
to concat I think it copies the two pieces of in a new memory area, so
for long string StringBuffer is bette, becuse it uses a better
structure, like linked list or something like this. I've had the same
problem in perl for extranting long fragments from longer logs, i've
solved it with an array of lines, rather than concat every thing in a
single variable.


Many thanks

Best regards

Il giorno sab, 24/01/2009 alle 22.57 +0100, Kai Willadsen ha scritto:
> 2009/1/24 Stephen Kennedy <stevek gnome org>:
> > As you say very large blocks are unlikely to be useful so I like the idea of a
> > simple hard limit on the length of block considered for inline highlighting.
> 
> Great - I've committed a modified version of my earlier patch. It's
> not ideal, but it should stop the 'hanging' without introducing
> obvious regressions.
> 
> > Wouldn't block splitting be tricky because the blocks will not in general be the
> > same length, and would require some heuristic to try to keep them matched?
> 
> My thought was that the splitting could be very rough - just split
> every 5000 characters or so, and compare what you have. If sequence A
> is 8000 characters and B is 12000 characters, you get one comparison
> of 0:5000, one comparison of 5001:8000 to 5001:10000, and you just
> highlight the rest of B as changed. On the other hand, it's not
> immediately obvious that the complexity is worthwhile; other options
> like re-running a comparison *with* line breaks before doing the
> inline highlighting might be produce better results.
> 
> Kai
-- 
Bartolomeo Nicolotti
SIAP s.r.l.
www.siapcn.it
v.S.Albano 13 12049
Trinità(CN) Italy
ph:+39 0172 652553
centralino: +39 0172 652511
fax: +39 0172 652519