git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Compression and dictionaries

From
Jon Smirl <jonsmirl@gmail.com>
Date
Aug 16, 2006, 14:43 UTC
Message-ID
<9e4733910608160743k22362dc4r4fa22c791707c73c@mail.gmail.com>
In-Reply-To
<Pine.LNX.4.63.0608160908070.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On 8/16/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 34 quoted lines
> Hi,
>
> On Wed, 16 Aug 2006, Shawn Pearce wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hi,
> > >
> > > On Wed, 16 Aug 2006, Jon Smirl wrote:
> > >
> > > > On 8/16/06, John Rigby <jcrigby@gmail.com> wrote:
> > > > > Sorry if this is off topic, but could the dictionary be used to make
> > > > > git-grep alot faster?
> > > >
> > > > It would be almost instant.
> > >
> > > But only if you are not using a regular expression, but a single word.
> >
> > Yes and no.  If the inverted index contains terms broken by some
> > known pattern (e.g. break on word-type boundaries) and the regex
> > in question has constant sections (it should, otherwise it might
> > as well just be '.') then you can reduce your search space to a
> > fraction of the overall data by looking at the inverted index to
> > select likely terms, select the related revisions containing those
> > possible terms, then run the regex only on those revisions.
> >
> > Sure you would be possibly pulling out a number of false positives
> > but if the constant sequence(s) in the regex reduce your search
> > space to below 1/2 of the overall data that's probably a lot less
> > I/O and CPU required to complete the query, even if you have to
> > read the entire dictionary and apply each term in the dictionary
> > to the regex to look for those possible matches.
>
> So it would speed up the search, but no, in case of regular expressions,
> particularly any interesting one, the result would not be instantaneous.

Instant is a relative term. Google is instant compared to running grep over 10TB of data. How long would that take, a month?

Shawn is correct, the inverted indexes are used to eliminate as many files as possible. So the response time is a more of a function of how many hits you have instead of how big the data set is. Of course if you give it a pattern that matches everything it will just as slow as grep. Give it a pattern that is only in one file and detectable by the index and it will be very fast. If you are going to give it a bunch of patterns that aren't in the index, then we need to adjust how the index is built.

-- 
Jon Smirl
jonsmirl@gmail.com
Previous: Johannes SchindelinNext: linux@horizon.com
Message 9 of 10 in “Re: Compression and dictionaries”
  1. linux@horizon.comAug 15, 2006
  2. Jon SmirlAug 15, 2006
  3. Jon SmirlAug 15, 2006
  4. linux@horizon.comAug 16, 2006
  5. Jon SmirlAug 16, 2006
  6. Johannes SchindelinAug 16, 2006
  7. Shawn PearceAug 16, 2006
  8. Johannes SchindelinAug 16, 2006
  9. Jon SmirlAug 16, 2006
  10. linux@horizon.comAug 17, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.