On Thu, 14 Aug 2008, Nicolas Pitre wrote:
I seriously doubt that.
Nico, it's really easy to say "I wave my magic wand and nothing remains".
It's hard to actually _do_.
> One optimization with pack v4 was to have delta chunks aligned on tree
Even if you do that, please take a look at the performance characteristics
of modern CPU's.
Here's a hint: the cost of a cache miss is generally about a hundred times
the cost of just about anything else.
So to make a convincing argument, you'd have to show that the actual
memory access patterns are also much better.
No, zlib isn't perfect, and nope, inflate_fast() is no "memcpy()". And
yes, I'm sure a pure memcpy would be much faster. But I seriously suspect
that a lot of the cost is literally in bringing in the source data to the
CPU. Because we just mmap() the whole pack-file, the first access to the
data is going to see the cost of the cache misses.
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
| David Miller | Re: Slow DOWN, please!!! |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jan Engelhardt | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
