On Tue, 12 Feb 2008, Johannes Schindelin wrote:I'd suggest making the memory window smaller yet. 512MB is a *big* amount of memory, if you fill it up, and end up using an O(n**2) algorithm on the objects within the window (which it is: the repacking algorithm is O(n) in _total_ objects, but the constant part is basically O(winsize^2). I'd suggest that a reasonable window memory limit is around just a few megabytes (eg 4MB to maybe 64MB). If you have "normal" source files, you're still going to be limited by the window _count_ size (assume normal source files are in the few tens of kB), and for those occasional large files, you'd better hope that the sort heursistics are good enough. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Kok, Auke | Re: Linux 2.6.21-rc1 |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Jeff Garzik | Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Eric Dumazet | [PATCH] net: remove superfluous call to synchronize_net() |
