On Tuesday 20 September 2005 23:17, Jean Delvare wrote: > Hi Andreas, > > > > http://jdelvare.net2.nerim.net/quian/2.6/ > > > > Quian relly looks nice! > > Thanks :') > > > I'm eager to learn how much cpu and I/O bandwidth Quian consumes, and > > how fast it feels locally ;) > > It's rather hard to evaluate the bandwidth, as it depends on many > factors, such as the number of users, the actual use (frequency and > nature of requests), the average size of source files, the number and > sizes of patches in the series, etc. > > The setup I pointed you to is powered by my home server, that is, an old > Pentium III at 800 MHz with 256 MB memory and a 256 kB/s network > access. From your question, I can guess it felt a bit slow.
No, it wasn't really slow. > This remains viable for casual use and a limited number of users, methinks. > > Locally, I just tried on a reasonably fact machine: an Athlon XP 2400+ > with 512 MB memory and 100 Mb/s network access. In these conditions, > Quian use qualifies as smooth. With a 65 patch series (44.7 MB in bz2), > navigation is immediate, annotated file view is below 0.5 s (up to 1s > for really large files), highlight is almost immediate (thanks to > disk/system cache I presume), file diff is between 1 and 3 seconds > depending on the file and patch, files list is the slowest operation, > typically between 3 and 5 seconds. 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. > It should be possible to improve the performance by not using bz2 > patches. Most commands seem to be unaffected but at least the files > list (files.php) should be. The actual benefit obviously depends on the > CPU/disk speed ratio of the server. Shouldn't be necessary (see above). > > One thing we might want to add to quilt annotate is a view that > > displays the patch names side by side with the source code as Quian > > does. I so far didn't bother doing that because the code for figuring > > out how to properly align things scared me off. (Still shouldn't be > > more than a few lines of shell code...) > > I agree it would be convenient to have that in quilt, maybe as an option > though. Beware that in Quian I convert the patch names to versions > (remember I wrote it with Linux version patches in mind), but in quilt > the annotations are likely to be much longer than that, so the annotated > source may end up being very wide. If quilt can do that, it will save > some code in Quian and, more importantly, it will let me generate the > HTML page on-the-fly rather than buffering the entire quilt annotate > output as is currently needed. It might improve performance a bit. We can try that. > > Another would be to somehow get annotate to print which modifications > > are "underneath" the most recent modification, in case that's useful. > > Deletions might be interesting as well. > > My approach to this problem has been the -p option of annotate. If the > user wants to know what happened before the version currently displayed > for a given line, he/she can ask for the annotated source as it was > right before that change happened. I think it's more realistic, as the > list of changes which have affected a given line, without the context > in which each change happened, is not such a valuable information IMHO. IMO the two are quite different views. > > > 1* File moves are not handled. As moving files around happens > > > frequently in the lifetime of a large project, some history is not > > > visible using Quian. I have plans to improve quilt's annotate > > > command, but it sounds like a quite complex task, as patch files do > > > not clearly notify file moves. > > > > You won't get that information with patch based tools, and I don't > > think it makes a lot of sense trying to reconstruct this information. > > I think it does, simply because I have an immediate need for it ;) > Detecting the moves is not that complex, a few heuristics will do. > Doing it fast and reliably is more of a problem. Integrating this in > quilt's logic is the most difficult part. I'll give it a try eventually. Until proven wrong, I'm against adding things like this. Thanks, Andreas. _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
