On 09/10/2010 11:57 AM, Jakub Narebski wrote: > Lubomir Rintel <lkundrak@xxxxx> writes: > >> I thought something like this could be a starter for better handling long >> gitweb project lists (such as http://pkgs.fedoraproject.org/gitweb/). >> >> Could anyone please take a look? > > What do you mean here by "better handling"? > > Is the problem server performance for large number of projects? If > this is the problem, perhaps better solution would be to use caching > (work in progress). They already moved to using my caching layer, mainly because I could create an RPM for them and the fact that my caching code is slightly more battle tested. > Is the problem large projects-list page and bandwidth? There was a > patch adding transparent compression of pages generated by gitweb > would be a better solution; perhaps this together with caching (to > avoid performance hit on CPU; note that usually gitweb performance is > I/O and not CPU-bound). > > Is the problem client rendering performance on large page with large > table? If it is, then paginating output, or adding project search > like in gitweb fork used on http://repo.or.cz is correct solution. > > > So which is it? I think the issue is just having something like 10K projects all suddenly staring you in the face on a single page, it's not so much a technical problem with gitweb itself as a mental problem of dealing with a giant webpage like that. So far the Fedora guys seem happy with the way things are (well except for the fact that their front page takes something like 2 hours to build, which has it's own set of problems). Just some additional food for thought. - John 'Warthog9' Hawley -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html