Commit Graph

12 Commits

Author SHA1 Message Date
Bryan O'Sullivan
a150198558 store: implement fncache basic path encoding in C
(This is not yet enabled; it will be turned on in a followup patch.)

The path encoding performed by fncache is complex and (perhaps
surprisingly) slow enough to negatively affect the overall performance
of Mercurial.

For a short path (< 120 bytes), the Python code can be reduced to a fairly
tractable state machine that either determines that nothing needs to be
done in a single pass, or performs the encoding in a second pass.

For longer paths, we avoid the more complicated hashed encoding scheme
for now, and fall back to Python.

Raw performance: I measured in a repo containing 150,000 files in its tip
manifest, with a median path name length of 57 bytes, and 95th percentile
of 96 bytes.

In this repo, the Python code takes 3.1 seconds to encode all path
names, while the hybrid C-and-Python code (called from Python) takes
0.21 seconds, for a speedup of about 14.

Across several other large repositories, I've measured the speedup from
the C code at between 26x and 40x.

For path names above 120 bytes where we must fall back to Python for
hashed encoding, the speedup is about 1.7x.  Thus absolute performance
will depend strongly on the characteristics of a particular repository.
2012-09-18 15:42:19 -07:00
Adrian Buehlmann
f5ca6da4d6 parser: use PyInt_FromSsize_t in index_stats
Eliminates

  mercurial/parsers.c(515) : warning C4244: 'function' : conversion from
  'Py_ssize_t' to 'long', possible loss of data
  mercurial/parsers.c(520) : warning C4244: 'function' : conversion from
  'Py_ssize_t' to 'long', possible loss of data
  mercurial/parsers.c(521) : warning C4244: 'function' : conversion from
  'Py_ssize_t' to 'long', possible loss of data

when compiling for Windows x64 target using the Microsoft compiler.

PyInt_FromSsize_t does not exist for Python 2.4 and earlier, so we define a
fallback in util.h to use PyInt_FromLong when compiling for Python 2.4.
2012-05-09 09:58:50 +02:00
Matt Mackall
0fa9895915 util.h: replace ntohl/htonl with get/putbe32 2012-04-16 11:26:00 -05:00
Matt Mackall
0ba5fb4cce util.h: more Python 2.4 fixes 2012-04-10 16:53:29 -05:00
Matt Mackall
fd4256c9b1 util.h: unify some common platform tweaks 2012-04-10 12:07:14 -05:00
Matt Mackall
935d420846 util.h: move Py_ssize_t bits from mpatch.c 2012-04-10 12:07:09 -05:00
Matt Mackall
afeb0ce18a util.h: add a typedef for Py_ssize_t with Python 2.4 2012-04-08 22:17:51 -05:00
Martin Geisler
a76e121863 backout of e4cb9628354c
Matt and a majority of crew did not like this approach.
2011-01-27 11:15:08 +01:00
Martin Geisler
d23e1973c2 specify C indention style using Emacs file local variables 2011-01-26 12:05:01 +01:00
Renato Cunha
b985656666 util.h: Defined macros for working "with" PyStrings in py3k.
PyString* functions are defined as PyUnicode* to permit correct compilation in
both python 2.x and 3.x.
2010-07-02 16:21:40 -03:00
Renato Cunha
d3325144cd util.h: Add a PyInt_AsLong definition for usage in the inotify module. 2010-07-02 16:21:38 -03:00
Renato Cunha
9dcf925abb util.h: Utility macros for handling different Python APIs.
If we are in py3k, a IS_PY3K symbol is defined. Apart from that, byte strings
use the API defined in Python 2.6+ (_?PyBytes_.*). For Python < 2.6, the bytes
API is defined accordingly for mercurial usage (shameless copy from
bytesobject.h from Python's code). Some macros were backported from 2.6, as
inspired by rPath's pycompat.h.
2010-06-15 19:49:56 -03:00