User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060825 Minefield/3.0a1 Build Identifier: Quoting dbaron in bug 334064: New APIs should not take nsAC?String. They should take nsC?Substring (or nsC?String, if appropriate). nsAC?String exists only for backwards compatibility with the old string API; nsC?Substring is equivalent, but without the vtable pointer magic. Also, bzbarsky commented on measurable overhead with the string objects here. These strings exist in nsTextFrame as (PRUni)char * and a length, so these could be used straight through the gfxTextRuns. Reproducible: Always

The problem is really that we copy the strings (on linux only), not what they're passed in as.

> (PRUni)char * and a length That is error prone and should be forbidden IMHO. I have seen several examples in the Mozilla code base where it caused an exploitable buffer overflow that would not have happened had a string object been used. The use of PRUnichar* + length in the nsTextFrame/nsTextTransformer APIs is a bug that should be fixed, please don't propagate this bad design further.

> The problem is really that we copy the strings (on linux only), not what > they're passed in as. The problem is both. We first create some temporary string objects (and later destroy them), then copy them. The temp objects are quite noticeable in profiles.

Is this INVALID because nsA[C]String is just a typedef for ns[C]Substring now?

No. See comment 1 and comment 3. I guess the typedef thing just means the vtable magic is gone, which is a good start but not enough.

Umm, where exactly does gfxTextRun take a string? As far as I can tell, it only takes a void*.

Ah, looks like roc may have changed this stuff.... should reprofile. This bug is probably worksforme as-is.

Marking as WORKSFORME (see comment #7) until someone proves otherwise.