Here's a closer look at what's probably happening:

I briefly hit a bizarre case where a Ferret engine query took 10 seconds to find a document in 163 projects. However, running ANALYZE TABLE on the ngrams table resolved this completely. I suspect the ngrams join may require some tweaking (and maybe a bin/storage analyze). Analyzing the Maniphest table actually seems to improve performance by ~50% too (???) although that's not a very scientific measurement.

Yeah -- we'll take the patch in the latter case (porting lexers to PHP) but may not have time to review them for a while. We aren't interested in any version of options/support for using HTTP to talk to Pygments in the upstream.

Writing, deploying, and supporting an additional service is an enormous amount of work for us and not a solution I'm interested in pursuing for this problem

The only way forward on Pygments performance with upstream support is porting language lexers to PHP. Writing, deploying, and supporting an additional service is an enormous amount of work for us and not a solution I'm interested in pursuing for this problem: it burdens us with a large ongoing support cost instead of very small mostly-one-time lexer porting costs.

(As a side note, the way we'd support this on our ubuntu phabricator machine is to write an upstart script to start the pygments server on startup -- it would also restart the server if it died -- and to run the server under pypy for even more performance happiness.)

See PHI54 for some additional discussion.

Unclear if building a search engine by just doing a lot of JOINs actually scales or not. Seems OK here.

See also PHI45.

I'd probably lean towards just increasing the padding under the text to make sure the field is clearly separate from the one below it.

If that suggestion looks valid, I'd be happy to implement it (I'm thinking "Add RemarkupCaption into Control, render above actual field", and maybe "migrate Caption field to use that too").

See also PHI52.

No, we don't want to bring anything upstream if we don't support or maintain it.

@epriestley was just curious if any of the "Real Working Examples" could be brought into the resource folder in phabricator, this information is super useful and helps complete the product.

@mna Please follow our bug reporting guidelines if you feel you've encountered a bug. This task is several years old and not relevant.

Hi everyone, when I open the datepicker (e.g. via https://secure.phabricator.com/calendar/event/edit/form/default/ ) today (it is August 31st), then it defaults to today (August 31st).

See also PHI48.

A prototype of this is now available on this server (secure.phabricator.com). You can access it in Maniphest by using the Query (Prototype) field instead of the Contains Words field.

Whoops this is probably my bad :-/

I think there will be a trickle of these for a while, but we seem to have found the most common cases.

We'll consider offering instances in the Sydney region in the future, but this isn't really a valid feature request or bug report. Feel free to continue discussion on Discourse.

This is now in the wild, and nothing seems to have cropped up yet.