Open Bug 1421567 Opened 7 years ago Updated 1 year ago

Reduce the visits title to 256 chars

Categories

(Toolkit :: Places, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: mak, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [snt-scrubbed][places-performance])

We reduce the descriptions to 256 chars, we should do the same for the titles when they are inserted along with visits.
From a raw check on my everyday db I have about 130 pages with a longer title out of more than 100k. The savings are not huge, but it's something.
My DB has 159 records larger than 256, with an average length of 322 chars, out of 200,000 places.

Imposing a limit of 256 chars would save 10KB of title characters. Even if we assume that there are five index duplications of moz_places, that's 60KB out of a title of 90MB -- 0.06% of the total space.

My ten largest:

length(title)
-------------
1326
953
933
856
617
611
566
540
467
447

Three questions:

- If these things are so rare, why bother? It's an unnoticeable amount of space, but it's code change, a platform difference, and you know it breaks _somebody_'s workflow.
- How did you choose 256?
- Do you mean 256 grapheme clusters, 256 codepoints, 256 bytes?
There are a few reasons:
1. We can't exclude someone may try to abuse the large limit, our DBs are not much representative
2. the awesomebar searches through the whole title, a few long titles may cause a slowdown when hit
3. it's still stuff we pass around across ipc and write, and in most cases I expect this data to be unused
4. it would leave more space for useful data, like past visits

The 256 pick was a guess. In case of Description, we only show a minor part of it (3 short lines), so 256 covers all the needs. Titles are usually even shorter in the UI. You may point out the fact we search titles while we don't search description, but how is likely the user is searching for something he never saw?

Btw, the main point is reducing the current nonsense limit to something that makes sense, to avoid abuse.
The limit was about chars as the Sqlite unicode implementation intends them, codepoints I suppose.
The 256 limit is not carved in stone and it could change before we fix this.
See the related discussion in bug 1375896.
See Also: → 1375896
Severity: normal → S3

We want to make sure to investigate any knock on effects this may have with sync, also check the effect this may have on searching titles

Whiteboard: [fxsearch] → [snt-scrubbed][places-performance]
You need to log in before you can comment on or make changes to this bug.