prompt$ a very long command
^Cprompt$ █


Then you hit the Up key to retrieve very long command from the history and try to edit it, only to discover that the text you see on the screen is shifted by two characters from where it appears to be, and you can’t see where you’re typing anymore. A major annoyance!

Here’s how you can fix it: glue the bash prompt always go to the first column. To do this, include \033[G in your $PS1:

PS1="\[\033[G\]$PS1"

This code happens to be the ANSI escape code for moving the cursor to the first column. Your prompt will now start from the first column and write over the ^C you typed. The \[ and \] on the other hand are needed so that Bash does not count these movement codes when calculating the length of the prompt.

The Bash Prompt HOWTO is a great resource if you want to learn more about how and why to customize your prompt.

Update: Wow, I never expected this would spark such a lively discussion on Hackernews! People there suggest many alternative solutions to this problems, such as simply hitting Ctrl-C or Enter to get a clean line whenever this occurs, configuring a two-line prompt, or ditching Bash for Zsh.

Give an experienced cook a dull knife. The blade slips and he cuts himself. Give an inexperienced cook a sharp knife. He doesn’t hold it right and he cuts himself.

It occurred to me that there’s no way to tell the difference between the two from the outside. All we see is a cook with with a bloody hand, cursing the knife. In the same way there’s no way to tell the difference between programmers using tools too sharp or too dull for their skills.

The scary part is this: often there’s no way to tell the difference from the inside either. As programmers we tend to be pretty smart people, or at least we think we are. But smart people suffer from several crippling fallacies, two being:

• being experts in a field they think they are experts in others, and
• they tend to underestimate the value of experience and the effort it takes to become really good at something.

Together these imply that when forced to use a new tool we think we’ll be as productive as before a lot sooner than we think. We try to use it in ways that are unnatural and unsafe, get hurt, and then we blame the tool. We may even claim that the knife is dull, not knowing any better. Re-appropriating Paul Graham: “That Java project was bound to fail. How could it not? Java doesn’t even have X.”

We think knowing all sorts of things about programming languages means we don’t have to know how databases work. “All they do is push and pull bytes from the disk, right?” Or that knowing everything there is to know about pointers and recursion means we should ignore OOAD. (News flash! 99% of code written today doesn’t use recursion or pointers. Well, not directly anyway.)

Next time, try holding the sharp edge downwards. There are no bad programming languages, only bad programmers.

Update: Commentary on Hackernews.

Programming in JNI starts with defining a class with methods declared as native. Next you generate a C header file that declares functions that implement. Then you define these functions in a separate file and compile it into a shared library. We’ll use Linux and GCC in this example.

Suppose we need to know the name of the terminal device from which the JVM was launched. (A bit of a contrived example since you could just use /dev/tty.) From C you would do this by calling the POSIX functions isatty and ttyname. Let’s make a class that gives us access to them:

package ex;
public class TTYUtil {
    static { System.loadLibrary("ttyutil"); }
    public static native boolean isTTY();
    public static native String getTTYName();
}

The call to System.loadLibrary in the class initializer looks for a shared library and links it to the JVM. The file name depends on the operating system: on Windows this code would look for ttyutil.dll, on Linux and Solaris libttyutil.so.

The next step is compiling the Java code and generating the C header file:

$ javac ex/TTYUtil.java
$ javah ex.TTYUtil

The javah tool will create a C header file called ex_TTYUtil.h. This file contains the declarations for the C functions we have to define:

JNIEXPORT jboolean JNICALL Java_ex_TTYUtil_isTTY
  (JNIEnv *, jclass);

JNIEXPORT jstring JNICALL Java_ex_TTYUtil_getTTYName
  (JNIEnv *, jclass);

The idea is that the header file should be generated automatically during the build process so you should not modify it manually. If you need other declarations or #include statements you should use a different file.

Create ex_TTYUtil.c to define the C functions:

#include "ex_TTYUtil.h"
#include <unistd.h>

JNIEXPORT jstring JNICALL Java_ex_TTYUtil_getTTYName
  (JNIEnv *env, jclass cls)
{
    char *name = ttyname(STDOUT_FILENO);
    return (*env)->NewStringUTF(env, name);
}

JNIEXPORT jboolean JNICALL Java_ex_TTYUtil_isTTY
  (JNIEnv *env, jclass cls)
{
    return isatty(STDOUT_FILENO)? JNI_TRUE: JNI_FALSE;
}

These functions receive the JNI environment object as the first argument. The second argument is the class for static native methods and the object for non-static methods. The rest of the arguments, if any, are the method arguments from Java. The JNI environment is used for interacting with the virtual machine, like here the NewStringUTF function is used to create a new Java String object from a C string.

To compile and link the C code you can use

$ gcc -fPIC -c ex_TTYUtil.c -I $JAVA_HOME/include
$ gcc ex_TTYUtil.o -shared -o libttyutil.so -Wl,-soname,ttyutil

Now you should have libttyutil.so in your working directory. Let’s try using the library.

import ex.TTYUtil;
public class Test {
    public static void main(String[] args) {
        if (TTYUtil.isTTY()) {
            System.out.println("TTY: "+TTYUtil.getTTYName());
        } else {
            System.out.println("Not a TTY");
        }
    }
}

Compile this class like you normally would and then run it:

$ export LD_LIBRARY_PATH=.
$ java Test
TTY: /dev/pts/3

And what if the output is not connected to a terminal?

$ java Test | cat
Not a TTY

The JVM looks for native libraries in the paths specified in the system property java.library.path in addition to what’s normal for the operating system. Here we made the shared library available to the JVM temporarily by adding the current directory to LD_LIBRARY_PATH. To permanently install a shared library on Linux you would copy the .so to /usr/lib (or any other directory mentioned in /etc/ld.so.conf) and then run ldconfig.

The problem is that these programs need to communicate with a TTY (teletypewriter) device to find the screen size and to be able to write anywhere on the terminal window. You don’t notice this when using them from a terminal because the shell sets up their stdin and stdout so they are connected to the terminal.

When you launch a program from Java using Runtime.exec the stdin and stdout are connected to pipes handled by the JVM, not to a TTY device: it is as if you tried to launch less with something like less file.txt <jvm.in >jvm.out. Needless to say that wouldn’t work even from a terminal.

What you can do is redirect the stdin and stdout streams back to the original terminal device. To find the actual TTY device we would have to call the POSIX ttyname function with JNI, but luckily that’s not necessary: we can use /dev/tty, which is the controlling terminal for the current process.

An interesting application of this is to use less as a pager to show lengthy messages to a user, like database result sets:

import java.io.OutputStream;

public class Test {
    public static void main(String[] args) throws Exception {
        Process p = Runtime.getRuntime().exec(new String[] {"sh", "-c",
                "less >/dev/tty"});
        OutputStream out = p.getOutputStream();
        out.write("Lengthy message".getBytes());
        out.close();
        System.out.println("=> "+p.waitFor());
    }
}

max·im [mak-sim] noun

1. (now rare) A self-evident axiom or premise; a pithy expression of a general principle or rule.
2. A precept; a succinct statement or observation of a rule of conduct or moral teaching.

These are my maxims when designing software.

DONE is better. A design can never be perfect; you’ll always think of a way to make it better. A design should be just good enough to ship, rather than delay the release by months to make everything perfect. Consistency can be sacrificed for simplicity temporarily; you can (and should) refactor later.

A related concept is YAGNI (You Aren’t Gonna Need It). You think you need to build a frobnicator at some point for the project? Don’t start working on it yet: There’s a good chance you won’t need it, or you find one that someone has already made. Don’t build the framework for the bug tracker for the project before creating something that can be shipped.

DRY (Don’t Repeat Yourself) in any level. Information should have only one source. Functionality and control structures should not be repeated. Create abstractions and use ideas from other programming paradigms. In the spirit of YAGNI apply the rule of three: don’t spend an enormous effort on refactoring repetition until you see it 3 times.

Conservation of complexity, or “no silver bullet”: You can move complexity around but you can never reduce it beyond the level inherent to the problem domain. Good design is about deciding how to break complexity into reasonable chunks and distributing it between components: You can make the processing module simpler by moving some logic to the I/O modules. You can make the code simpler by moving complexity to the type system. You can make the interface simpler by making the code more complex. You decide what’s better.

Think about usability.  Even if you are creating a library that interfaces a banking application, far removed from the end user with a monitor and a keyboard, you have a a user: the person writing code that uses your library. Arrange the design so that it’s possible to create a reasonable user interface, whether it’s a GUI or an API.

Object obj = new Object();
WeakReference<Object> ref = new WeakReference<Object>(obj);

List<byte[]> filler = new LinkedList<byte[]>();
while (ref.get() != null) {
    filler.add(new byte[1000]);
}
System.out.println("Filler size " + filler.size());

When executed you would expect it to run out of memory: ref.get() will never return null because the referenced object cannot be garbage collected. The local variable obj still holds a reference to it. The filler increases in size indefinitely, and the program will ultimately crash with an OutOfMemoryError.

What really happens is this:

$ java test
Filler size 28186

Wait, what?!

It turns out that the Hotspot virtual machine analyzes the code, sees that the variable obj is not used after the while-loop, and rewrites the method while it is running so that the local variable is effectively removed. If you added something like print(obj) after the loop you would get the expected OOME. 

The behaviour is kind of fickle: the thresholds for compiling code depend on the VM options. I haven’t been able to reproduce this with the server VM for example. You also get an OOME if you make the filler grow faster by adding bigger arrays of bytes: you have to give the compiler enough loop iterations to be triggered.

This is called OSR (On Stack Replacement) compilation in the Hotspot VM. Quoting Kris Mok in About Printcompilation:

OSR in HotSpot is used to help improve performance of Java methods stuck in loops [6]. Without OSR, a method running in the interpreter can’t transfer to its compiled version even if there is one available, until the next time this method is invoked. With OSR, though, a Java method with long-running loops can run in the interpreter, trigger an OSR compilation in one of its loops, keep running in the interpreter until the compilation completes, and jump right into the compiled version without having to wait for “the next invocation”.

The process of “jumping right into the compiled version” sounds simple but in reality is anything but. The new method body does not start from the beginning but from the “back edge” of the running loop. The stack frame created by the interpreter is replaced by the one created by the JIT compiler. It is this process that is capable of removing local variables from the method.

You can see when OSR happens by using the PrintCompilation flag:

$ java -XX:+PrintCompilation test
    125   1       java.lang.String::hashCode (60 bytes)
    133   2       sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (490 bytes)
    158   3       java.lang.String::charAt (33 bytes)
    159   4       java.lang.String::indexOf (151 bytes)
    174   5       java.lang.Object::<init> (1 bytes)
    182   6       java.util.LinkedList$Entry::<init> (20 bytes)
    183   7       java.util.LinkedList::add (12 bytes)
    185   8       java.util.LinkedList::addBefore (52 bytes)
    348   1%      test::main @ 25 (78 bytes)
Filler size 28082

The %-flag in the second column tells us that OSR compilation happened.

Implications

This optimization has a big implication on when finalizers are run. Since obj is a local variable you would expect that its finalizer would not be called at least until after the method. But since the object is GC’d before the method ends, it is finalized as well. This special case is also noted in JSL 12.6.1:

A reachable object is any object that can be accessed in any potential continuing computation from any live thread. Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.

The lesson is you can’t depend in any way on when objects are finalized.

On-Stack-Replacement also affects performance in unexpected ways. The Azul Systems Blog has a very good post on this subject.

(Inspired by the Stackoverflow question Are WeakHashMap Cleared During A Full GC? Thanks to berry120 and jalopaba for contributing detailed answers. Tests run on OpenJDK 1.6.0_23.)

Let’s check what MySQL collations mean in practice. First create a table with three fields, each with the same data but a different collations:

CREATE TABLE test (
  en varchar(3) CHARACTER SET utf8 COLLATE utf8_general_ci,
  se varchar(3) CHARACTER SET utf8 COLLATE utf8_swedish_ci,
  es varchar(3) CHARACTER SET utf8 COLLATE utf8_spanish_ci,
);

Then let’s fill the columns with some data:

INSERT INTO test (en, se, es) VALUES ('A','A','A');
INSERT INTO test (en, se, es) VALUES ('Ä','Ä','Ä');
INSERT INTO test (en, se, es) VALUES ('N','N','N');
INSERT INTO test (en, se, es) VALUES ('Ñ','Ñ','Ñ');
INSERT INTO test (en, se, es) VALUES ('Z','Z','Z');
INSERT INTO test (en, se, es) VALUES ('Ö','Ö','Ö');
INSERT INTO test (en, se, es) VALUES ('Nz','Nz','Nz');
INSERT INTO test (en, se, es) VALUES ('Az','Az','Az');

Now comes the fun part. In English Ä=A, N=Ñ, and O=Ö so we get this ordering:

SELECT en FROM test ORDER BY en;
-- Result: A Ä Az N Ñ Nz Ö Z

In Spanish N and Ñ are different letters so we get this ordering:

SELECT es FROM test ORDER BY es:
-- Result: A Ä Az N Nz Ñ Ö Z

In Swedish Ä and Ö are not only separate from A and O; they are the last letters of the alphabet:

SELECT se FROM test ORDER BY se:
-- Result: A Az N Ñ Nz Z Ä Ö

Ok, that’s it for ORDER BY. What about indices?

mysql> ALTER TABLE test ADD UNIQUE INDEX idx_en (en);
ERROR 1062 (23000): Duplicate entry 'Ñ' for key 'idx_en'

Makes sense, N and Ñ are the same according to English! With Swedish you would get the same error. What about Spanish?

mysql> ALTER TABLE test ADD UNIQUE INDEX idx_es (es);
ERROR 1062 (23000): Duplicate entry 'A' for key 'idx_es'

Here N and Ñ are different, but A and Ä are considered still the same.

The default collation on many installations is Swedish because MySQL AB, the company that created the database, is a Swedish company. Next time you create a table don’t forget to set the collation to something that makes sense for your users.

The truth about text in MySQL

Strings in MySQL consist of an encoding marker and a list of bytes. The CHARSET function reads the encoding while HEX can be used to read bytes:

SELECT CHARSET("€"), HEX("€")
=> latin1, 80

This enables MySQL to use different encodings while working on a query. You can write a query that compares text columns in different encodings and returns the results where the text is the same, rather than the bytes that are stored.

I have everything set to utf8 and still the database gives me garbage!

That’s because of the MySQL client encoding. One query can return text in several different encodings, it’s unreasonable to expect the user software to check the encoding of each individual string. So all text returned by the MySQL client is encoded in only one encoding.

The fast and easy solution to encoding problems: set the MySQL client encoding.

How this is done depends on what you use to connect. If you work in PHP and the old MySQL functions you should use mysql_set_charset("utf8"). If you have an old version try mysql_query("SET NAMES utf8"). If you use MySQLi it would be mysqli_set_charset($link, "utf8") (or $link->set_charset("utf8") if you use the OO API).

What are the encodings in the tables good for, then?

When you create a table you can specify a character encoding for a column. It means how the MySQL server will convert text like “abc123″ to bytes that can be written to disk. The encoding affects two things:

1. the range of characters that can be stored,  and
2. the number of bytes the text will occupy on disk.

• latin1: the characters that you can store cover most European languages, and the text occupies 1 byte per character.
• utf8: you can store any(*) Unicode characters, and the text occupies from 1 to 3 bytes per character, depending on the character.

Other encodings exist, of course. For example latin2 has characters used in Eastern European languages. If you use ucs2 you can store any Unicode characters and the text occupies 2 bytes per character. If you are storing a lot of text in Japanese you may want to use ucs2 instead of utf8 because you are saving a third in the storage.

You can also specify a collation like utf8_general_ci for a column. It means how MySQL will sort the data. This affects indices and ORDER BY clauses. Cultures have different rules for alphabetic order: for example in Swedish Ä is the second to last letter of the alphabet, while in English it’s equivalent to A. So with Swedish collation you get a < b < ä and with English collation you get a = ä < b. Use the ordering your users expect. You can read more about collations in my other post.

What if you don’t specify an encoding and collation for the column? Then MySQL will use the default specified for the table, the database, or the server.

Converting encodings

Strings in MySQL consist of an encoding marker and a list of bytes. To convert strings from one encoding to another you can use the CONVERT(… USING …) function.  What CONVERT actually does is change both the marker and the bytes so that the resulting string is the same as the original; not very useful for fixing broken text.

The solution is stripping the encoding marker from the string before passing it to CONVERT. This is done by converting the string to “binary” first:

CONVERT(BINARY broken_text USING utf8)

I’ve written a detailed case study on fixing a particularly complicated MySQL encoding problem in another post.

Practical demonstration

Let’s create a table with columns in different encodings and fill it with some data.

CREATE TABLE test_encoding (
  utf8   varchar(4) CHARACTER SET utf8,
  latin1 varchar(4) CHARACTER SET latin1,
  latin2 varchar(4) CHARACTER SET latin2
);
INSERT INTO test_encoding (utf8,latin1,latin2) values ('A','A','A');
INSERT INTO test_encoding (utf8,latin1,latin2) values ('Ñ','Ñ','Ñ');
INSERT INTO test_encoding (utf8,latin1,latin2) values ('Ŕ','Ŕ','Ŕ');
INSERT INTO test_encoding (utf8,latin1,latin2) values ('☺','☺','☺');
INSERT INTO test_encoding (utf8,latin1,latin2) values ('€','€','€');

When you select the data from this table with select * from test_encoding you get the following results:

+------+--------+--------+
| utf8 | latin1 | latin2 |
+------+--------+--------+
| A    | A      | A      |
| Ñ    | Ñ      | ?      |
| Ŕ    | ?      | Ŕ      |
| ☺    | ?      | ?      |
| €    | €      | ?      |
+------+--------+--------+

Even though each column is encoded differently everything is still readable. This is thanks to the MySQL client encoding. The characters that could not be encoded are replaced with question marks: there is no Ñ in latin2, nor is there a Ŕ in latin1. The smiley face is not present in either.

The last line is interesting: the euro sign can be encoded in latin1 although technically it’s not really a latin1 character. This shows that MySQL’s latin1 is not really the standard ISO-8859-1 encoding, commonly known as “ISO latin 1″. In reality it is Windows-1252, the “Western European” encoding that also has curly quotes and other niceties where ISO-8859-1 has unprintable control characters.

To see that MySQL really is storing the columns in different encodings you could do this:

mysql> select utf8,hex(utf8),hex(latin1) from test_encoding;
+------+-----------+-------------+
| utf8 | hex(utf8) | hex(latin1) |
+------+-----------+-------------+
| A    | 41        | 41          |
| Ñ    | C391      | D1          |
| Ŕ    | C594      | 3F          |
| ☺    | E298BA    | 3F          |
| €    | E282AC    | 80          |
+------+-----------+-------------+

What happens when we compare two columns encoded differently?

mysql> select utf8,latin1 from test_encoding where utf8=latin1;
+------+--------+
| utf8 | latin1 |
+------+--------+
| A    | A      |
| Ñ    | Ñ      |
| €    | €      |
+------+--------+

MySQL knows that the character repertoire of latin1 is a subset of utf8, so it converts the latin1 column into unicode so that it can be compared. If however you try to compare latin1 with latin2 this is what happens:

mysql> select latin1,latin2 from test_encoding where latin1=latin2;
ERROR 1267 (HY000): Illegal mix of collations (latin1_bin,IMPLICIT) and (latin2_bin,IMPLICIT) for operation '='

Since neither latin1 and latin2 is a subset of the other, MySQL cannot compare the columns. To be able to compare them you have to convert at least one to unicode, e.g. by using CONVERT(.. USING ..):

select latin1, latin2 from test_encoding
where convert(latin1 using utf8)=latin2;

I hope this information is enough to solve any character encoding problems you may have with MySQL once and for all.

(*) Did I say utf8 can store any Unicode characters? That’s not really true. MySQL’s utf8 and ucs2 only store unicode from the basic multilingual plane (BMP), which includes “only” the characters U+0000 through U+FFFF. If you have MySQL 5.5 or later you have additional encodings to choose from: utf16, utf32, utf8mb4. These encodings You can read the details, as usual, in the official MySQL documentation.

input=[("USA", "New York"), ("USA", "San Francisco"), ("USA", "Los Angeles"),
      ("UK", "London"), ("UK", "Manchester"), ("UK", "Edinborough"),
      ("Spain", "Madrid"), ("Spain", "Barcelona"), ("Spain", "Granada"),
      ("Finland", "Helsinki"), ("Finland", "Oulu"), ("Finland", "Kuopio")]

into lists of cities grouped by country like this:

output=[("USA", ["New York", "San Francisco", "Los Angeles"]),
	("UK", ["London", "Manchester", "Edinborough"]),
	("Spain", ["Madrid", "Barcelona", "Granada"]),
	("Finland", ["Helsinki", "Oulu", "Kuopio")]

Also suppose that the application that you are working on is about preparing data for reports and that a lot of the application will be dedicated to creating such groupings. Often the data is accumulated by summing numbers instead of building lists. Sometimes groups have to be divided into subgroups, like regions within countries. You had better have some kind of a generic pattern for this grouping algorithm instead of inventing a new way of doing each time, right?

One the worst ways of doing it I have seen is this:

country = None
isFirst = True
output  = []
cities = None

if len(input) > 0:
    for countryCity in input:
	if country != countryCity[0]:
	    if not isFirst:
		output.append((country, cities));

	    isFirst = False
	    country = countryCity[0]
	    cities = [countryCity[1]]
	else:
	    cities.append(countryCity[1])

    output.append((country, cities))

It gets the job done and didn’t take more than 5 minutes to write, but it’s brittle. The group is closed in two different places. It’s not immediately obvious what to change to group by multiple levels. If the processing logic was any longer doing this is like leaving a time bomb in the code base.

What I have found clearest in these cases is a nested loop like this:

while there is more input:
    open new group
    while there is more input and we're in the group:
	accumulate data for the group
	get next input
    close the group

An example in Python for the problem at hand would be something like this:

output = []
inputIter = iter(input)
countryCity = next(inputIter, None)
while countryCity != None:
    # open new group
    country = countryCity[0]
    cities = []

    while countryCity != None and country == countryCity[0]:
	# accumulate data for group
	cities.append(countryCity[1])
	countryCity = next(inputIter,None)

    # close group
    output.append((country, cities))

Here it’s pretty clear where a group is opened, where the data is accumulated, and where it is closed. Also it’s clear what to do if a second level of grouping is needed: the loop that accumulates data has to have this same structure inside. For example:

while countryCity != None:
    country = countryCity[0]
    regions = []
    # group by country
    while countryCity != None and country == countryCity[0]:
	region = countryCity[1]
	cities = []
	# group by region
	while countryCity != None and region == countryCity[1]:
	    cities.append(countryCity[2])
	    countryCity = next(inputIter,None)
	regions.append((region, cities))
    output.append((country, regions))

Network latency makes using AJAX applications like Google instant search, or even the common autocomplete field, feel like running in treacle*. Having the browser run to the server for more data every time the user pushes a key just doesn’t work well. Many times the data doesn’t even change that often, so one solution is to let the browser cache it. This is how you do it in CakePHP.

One way to implement the search suggest feature is with the Scriptaculous AJAX autocomplete field. While you type it sends frequent requests to the server. In a high-latency setting you may have to wait seconds to obtain the response. Worse still, sometimes the responses arrive out of order.

You get much better responsiveness if you preload the data and use Autocomplete.Local. It works a little differently from AJAX autocomplete in that the data has to be a Javascript array. If you create a controller action /search/suggestData that returns all data as JSON array, you can load the “local” autocomplete data with AJAX. So you could add this to your default layout:

<input id="search" autocomplete="off"/>
<div id="search_suggest" style="display:none;"></div>
<script type="text/javascript">
new Ajax.Request('<?php echo $html->url('/search/suggestData') ?>', {
    method: 'get', // Important! Only GET requests are cached.
    onSuccess: function(response) {
	var suggestData = response.responseJSON;
	new Autocompleter.Local('search_autocomplete', 'search_suggest', suggestData, { });
    }
});
</script>

But that’s not the full story. A search suggest feature should have thousands of suggestions to be useful. Adding all of that for every single page view amounts to significant increase in bandwidth use. Since the data doesn’t change that often, you can make the browser store it in its local cache.

Basically all you need is the Expires HTTP header and make sure you make GET requests. POST requests are not cached. The next time the call is made the browser will serve it from disk and it will be ultra fast. For example, to generate the JSON necessary for the search suggest feature you could use this controller action and view:

// app/controllers/search_controller.php
class SearchController extends AppController {
    function suggestData() {
        header('Expires: '.date('r', strtotime('+1 day')));
        header('Content-type: application/json; charset=utf-8');
        // The top 5000 search words as an array()
        $this->set('data', $this->Search->top5kSearches());
    }
}

// app/views/search/suggestData.ctp
<?php echo json_encode($data) ?>

If the data doesn’t change at all you can set the cache expiry date a lot further into the future. Here it’s set to 1 day.

How many search suggestions should you include, then? As many as possible, but bear in mind that Autocomplete.Local finds its matches by doing a linear search through the data array. With 5000 entries in the array you still get decent performance. It’s not hard to replace the search logic to use e.g. a binary search though.

I have observed this trick to shorten response times from several seconds to about zero for users that have a slow link to the web server. It makes a world of difference for autocomplete fields.

*) Oh, by the way. Apparently it’s easier to swim in treacle than in water. Go figure.