Re: [Quilt-dev] [ANNOUNCE] Quian

[Jean Delvare]

Hi Andreas,

[Andreas Gruenbacher]
> We could use $(files_in_patch ...|sort) instead of 
> $(files_in_patch_ordered ...) in the files command. I'm not sure that
> the ordered variant is very useful for the files command.

To my surprise, it did not significantly improve speed at first. This
made me wonder what else in this script could require that much time,
as the "quilt diff" command doesn't look terribly complex. It happens
that what takes much time is the gathering of file status (modified,
added of deleted), which is not even displayed by default, so it is
computed for absolutely nothing until -v is used (and -l isn't). That
part alone accounted for about 80% of the total execution time. I just
committed a fix to CVS. Odd that nobody noticed before. Needless to say
that Quian behaves much better now :)

With this fix, the cost of files_in_patch_ordered compared with
files_in_patch | sort was easier to measure. I see a 12% improvement
when switching to the latter, and I agree with you on the fact that
preserving the original order of the files there isn't really
important, so we could switch to the fastest option. If we do,
sort.test (and reorder.test, see my other post) will need to be
updated. I guess that the question is down to: "Are these 12% worth the
change." Opinions are welcome.

I'd add that I believe that the files function is broken. I've noticed
at least two problems:

1* "quilt files {unapplied patch}" returns without a message. As the
case is not handled, I'd expect an error message. Or we might try to
support that case, it shouldn't be that hard.

2* "quilt files -v {applied patch}" returns possibly bogus file status.
If I read the code properly, the comparison is done between the state
prior to applying the specified patch and the state after applying the
top patch, rather than after applying the specified patch. That might
be different if patches inbetween recreate or delete files. An
immediate fix would be to make specifying a patch and -v mutually
exclusive options. Really fixing the feature looks feasable but
non-trivial.

Thanks,
-- 
Jean Delvare