Блогчетање

How much memory overhead does your Docker container really have?

TL/DR:

Each container had around 7.4MiB of host memory overhead for Docker shim and proxy services.
Binding only IPv4 port got that down to 6.2MiB per container by running half the proxies.
Configuring Docker with userland-proxy: false avoids the proxy altogether and gets overhead down to 4.3MiB
Memory usage between Ubuntu and Alpine was mostly the same other than a few exceptions.
Rust (1MiB) beats Go (1.5MiB), with Python in the middle (9.4/10.9MiB), followed by TypeScript (~15MiB) and C# last (18.5MiB).
Measuring after 200 requests and 15s of settling afterwards, keeps the order but TypeScript and C# fall further behind: Rust (1MiB), Go (3/5MiB), Python (9.7-11MiB), TypeScript (20/26MiB) and finally C# (30/31MiB).
dockerd at ~70MiB and containerd at ~50MiB were relatively stable between runs.
Ubuntu surprisingly beat Alpine variants in Go (2.9MiB vs 4.9MiB) and Python (9.7MiB vs 11.1MiB) while losing in TypeScript (26.2MiB vs 20.1MiB).

Scope

I was looking to understand overhead of using Docker to run simple network services (basic "Hello World" API service) in different language runtimes and using different base OSes (Alpine Linux and Ubuntu 26.04), and any simple systemic options to optimize that a bit.

The five languages I wanted to compare were Go, Rust, TypeScript, Python and C#.

Methodology

The benchmark was really simple: a basic API handler returning "Hello World" string using whatever the Claude Code/Codex thought made sense as the simplest web framework for the language: Tokio for Rust, ThreadingHTTPServer for Python, node:http for TypeScript, net/http for GoLang and WebApplication for C#. This is not representative of production loads and is mostly to understand the overhead before you start adding actual business logic inside.

Early on, Claude Code mentioned 2 proxy processes for each container: one to bind to IPv4 port, and another to bind to IPv6 port. This made me check: in the idle state (containers stopped and then restarted), baseline memory usage was around 7.4MiB when both IPv4 and IPv6 were proxied, and 6.2MiB with just IPv4 (down by about 1.2MiBper container). From there on, I focused on running with only IPv4 assuming you can always choose which one you prefer for your internal docker communication.

For every run of the benchmarks, I'd stop the docker services (docker compose stop), restart them and only then run the benchmark script with sudo to collect PSS data as RSS was double-counting. Claude Code and OpenAI Codex both contributed to the benchmark scripts which are pushed to git@github.com:dsegan/docker-memory-overhead.git.

To gather idle data, I did sudo scripts/report.sh report --requests 0 --settle 15 --samples 1, and for warm data I did sudo scripts/report.sh report --requests 200 --settle 15 --samples 5.

Idle Results for both IPv4 and IPv6 being served

service	current	WS	anon	file	kernel	peak	tasks	host tax	estimate	endpoint
csharp-alpine	18.1	18.1	8.4	7.9	1.6	18.5	22	7.4	25.5	ok
csharp-ubuntu	18.5	18.5	8.9	7.9	1.8	19.3	22	7.4	25.9	ok
go-alpine	1.6	1.6	1.1	0.0	0.5	4.9	5	7.3	8.9	ok
go-ubuntu	1.6	1.6	1.2	0.0	0.5	4.7	5	7.6	9.2	ok
python-alpine	10.9	10.9	10.4	0.0	0.5	13.5	1	7.4	18.3	ok
python-ubuntu	9.4	9.4	8.8	0.0	0.6	10.1	1	7.7	17.1	ok
rust-alpine	0.8	0.8	0.2	0.0	0.6	5.2	9	7.4	8.1	ok
rust-ubuntu	1.0	1.0	0.4	0.0	0.6	5.2	9	7.4	8.4	ok
typescript-alpine	13.0	13.0	11.9	0.0	1.1	16.7	7	7.3	20.3	ok
typescript-ubuntu	17.6	17.6	16.4	0.0	1.2	21.8	7	7.4	25.1	ok
Sum	92.5	92.5	67.7	15.8	9.0	119.9	88	74.3	166.8	10/10 ok

Idle Results with just IPv4

service	current	WS	anon	file	kernel	peak	tasks	host tax	estimate	endpoint
csharp-alpine	21.3	18.5	8.4	10.9	1.6	21.6	22	6.0	24.5	ok
csharp-ubuntu	21.9	18.7	8.8	11.3	1.8	22.5	23	6.3	25.0	ok
go-alpine	3.7	1.5	1.0	2.2	0.5	5.4	5	6.4	7.9	ok
go-ubuntu	1.7	1.6	1.1	0.1	0.5	4.7	5	6.0	7.6	ok
python-alpine	12.3	10.9	10.4	1.3	0.5	14.7	1	6.3	17.2	ok
python-ubuntu	10.6	9.4	8.8	1.1	0.6	11.7	1	6.4	15.8	ok
rust-alpine	0.8	0.8	0.2	0.0	0.6	5.5	9	6.2	7.0	ok
rust-ubuntu	1.1	1.0	0.4	0.1	0.6	5.4	9	6.1	7.1	ok
typescript-alpine	14.7	13.1	11.9	1.6	1.2	17.8	7	6.3	19.4	ok
typescript-ubuntu	19.2	17.7	16.4	1.5	1.2	23.2	7	6.3	23.9	ok
Total	107.3	93.2	67.4	30.1	9.1	132.5	89	62.3	155.4	10/10 ok

Warm results with both IPv4 and IPv6

service	current	WS	anon	file	kernel	peak	tasks	host tax	estimate	endpoint
csharp-alpine	50.5	30.1	11.1	37.3	1.9	50.9	24	7.7	37.8	ok
csharp-ubuntu	48.7	31.5	11.6	35.1	1.9	49.2	23	7.8	39.2	ok
go-alpine	4.9	4.9	2.1	2.3	0.5	6.1	6	7.7	12.7	ok
go-ubuntu	4.9	2.9	2.1	2.3	0.5	6.2	5	7.8	10.7	ok
python-alpine	17.7	11.1	10.4	6.6	0.6	20.0	1	7.8	18.9	ok
python-ubuntu	13.9	9.7	8.9	4.3	0.7	15.6	1	7.8	17.5	ok
rust-alpine	1.3	0.9	0.2	0.5	0.6	5.1	9	7.7	8.6	ok
rust-ubuntu	1.5	1.1	0.4	0.4	0.6	5.2	9	7.7	8.8	ok
typescript-alpine	44.9	20.1	14.1	29.4	1.4	47.1	7	7.9	28.0	ok
typescript-ubuntu	58.9	26.2	20.2	37.2	1.5	59.6	7	8.0	34.3	ok
Total	247.2	138.5	81.1	155.4	10.2	265.0	92	77.9	216.5	10/10 ok

Warm results with just IPv4

service	current	WS	anon	file	kernel	swap	peak	tasks	host tax	estimate	endpoint
csharp-alpine	38.1	25.7	11.1	24.8	1.8	0.0	43.3	24	6.5	32.2	ok
csharp-ubuntu	39.0	25.3	12.3	24.5	1.9	0.0	45.0	24	6.3	31.6	ok
go-alpine	2.7	2.2	2.0	0.5	0.5	0.1	4.9	5	6.5	8.7	ok
go-ubuntu	3.7	2.6	2.1	1.2	0.5	0.0	5.5	5	6.3	8.8	ok
python-alpine	12.1	10.8	10.4	1.2	0.4	0.0	19.0	1	6.3	17.1	ok
python-ubuntu	10.8	9.3	8.9	1.6	0.4	0.0	14.1	1	6.4	15.6	ok
rust-alpine	1.3	0.8	0.2	0.5	0.6	0.0	5.2	9	6.2	7.0	ok
rust-ubuntu	1.5	1.0	0.4	0.4	0.6	0.0	4.9	9	6.3	7.3	ok
typescript-alpine	19.8	15.9	14.4	4.2	1.2	0.0	40.5	7	6.4	22.4	ok
typescript-ubuntu	26.2	21.6	20.1	4.8	1.3	0.0	51.8	7	6.4	28.0	ok
Total	155.2	115.2	81.9	63.7	9.2	0.1	234.2	92	63.6	178.7	10/10 ok

userland-proxy: false

service	current	WS	anon	file	kernel	peak	tasks	host tax	estimate	endpoint
csharp-alpine	47.1	33.9	9.2	35.8	1.7	49.1	23	4.4	38.3	ok
csharp-ubuntu	50.6	38.4	13.6	35.2	1.8	51.3	22	4.3	42.7	ok
go-alpine	4.8	3.6	2.1	2.3	0.5	6.2	5	4.3	7.9	ok
go-ubuntu	5.1	3.8	2.3	2.3	0.5	6.1	5	4.5	8.3	ok
python-alpine	17.3	12.4	10.4	6.3	0.5	19.8	1	4.3	16.7	ok
python-ubuntu	15.4	10.9	8.9	5.9	0.6	17.3	1	4.2	15.1	ok
rust-alpine	1.3	1.1	0.2	0.5	0.6	5.1	9	4.5	5.6	ok
rust-ubuntu	1.5	1.3	0.4	0.4	0.6	5.4	9	4.3	5.6	ok
typescript-alpine	44.1	19.3	14.4	28.4	1.2	46.3	7	4.5	23.8	ok
typescript-ubuntu	51.9	25.5	20.3	30.3	1.3	52.6	7	4.3	29.8	ok
Total	239.1	150.2	81.8	147.4	9.3	259.2	89	43.6	193.8	10/10 ok

Options & Alternatives

If getting the overhead down is the goal, there are tools which you can leverage which may or may not be suitable:

Drop the userland-proxy from Docker Daemon.
Avoid languages which aggressively use up your memory: Rust and Go are clear winners, with a surprising show from Python staying mostly stable, and bad results from NodeJS and C#.
Podman is daemonless and might avoid the overhead altogether.
LXD/Incus might be worth exploring, but they provide system containers vs application containers.
Systemd units with sandboxing (but without filesystem isolation) between services should get the overhead down to zero.
Snaps to add filesystem isolation to a feature-set similar to systemd units — but not designed for this type of use-case.
...

Conclusions

Docker is not well suited to running on low-memory platforms as always-running daemons take around 100MiB of memory, on top of 4-6-8MiB of additional memory per container: a system with 20 containers will use up 220MiB of RAM just to orchestrate containers, and that's without any service actually operating. With 20 Rust or Go services you might just about fit into 256MiB of RAM, but you'll be looking OOMs in the face. If you are using anything else, 512MiB is going to be low as well.

Finally, take the above results with a (big) grain of salt: benchmark code has been built by LLMs, and it is not representative of any production loads.

Postscriptum on LLMs: pelicans on bicycles with a twist

Judge Dread? Or welcome to my first LLM-related post.

As LLMs and especially coding agents became part of our daily workflows, we started relying more on actual judgement of models we use — judgement, to me, is any decision they default to based on their training and pre-processing without humans actually directing them with prompts or skills.

It might be a simple decision about using tabs or spaces, or a more complex one about how to structure your tests and test fixtures, but you can already get a lot done by offloading decision-making as well.

While this is fast improving, I wanted to test my understanding by asking them to do an extremely common test by Simon Willison of generating a vector image of a pelican riding a bicycle, but with a twist: instead of asking for an SVG, ask for a conceptually different vector format PostScript (really, a programming language), which is closer to the plotting/printing model from 80s, with instructions like moveto, Y-axis actually going upwards, for loops, matrix transformations etc — enough difference in semantic interpretation and less training data to throw a frontier model off :)

My expectation was that they would be a generation or two behind compared to what Simon is getting with SVGs.

I'll let you be the judge if my foresight was right or not.

Prompt: Generate a native PostScript image of a pelican riding a bicycle.

ChatGPT 5.6 Sol Extra-High

Claude Fable 5 High

Claude Opus 5 Extra

Gemini 3.1 Pro High

Gemini 3.7 Flash Thinking v2 (v1 had a syntax error which required fixing)

Qwen 3.7 Plus Thinking

Qwen 3.8 Max Thinking

Some quick notes

I tried converting PostScript files with ImageMagick first, but after seeing it miss a few things during conversion, decided to use GhostScript loader from within Inkscape instead and export a PNG out.
Gemini 3.7 Flash had a broken first version which it was able to fix with the Ghostscript error message passed back (I think it was wrong parameters for ellipse command).
Opus 5 took around 4 iterations of rendering to a raster image and reviewing (also hitting a PS syntax error), but managed to improve with each cycle. I did not check the costs, but it was probably expensive :)
My first few attempts were with a slightly different prompt of "Make an PS or EPS (PostScript) of a pelican riding a bicycle" ("an" typo included — I probably went for EPS first and never corrected the language). This resulted in greyscale images in ChatGPT confirming that this might be worth looking into. I did not approach it scientifically at all, but switching to "Generate" to match Simon's version always produced a colorized version.
All of the text in this post was hand-typed, including the em-dashes.

Трајање ауторских права у Србији

Ауторска права у Србији пре 21. века

Почетком двадесетог века, у Србији је на снази био Аустроугарски Закон о ауторским правима на дела књижевности, уметности и фотографије [1895] од 26. децембра 1895. са изменама од 26. фебруара 1907. који је опште трајање ауторских права на заштићена дела ограничавао на 30 година од смрти аутора.

Али, током двадесетог века, ауторска права у Србији (Краљевини Србији, Краљевини Срба, Хрвата и Словенаца, те Краљевини па Федеративној народној, Социјалистичкој федеративној и коначно Савезној републици Југославији) су регулисана са више закона:

27. децембар 1929. — Закон о заштити ауторског права[1929] — ступио на снагу даном објаве са ретроактивним важењем
6. јул 1931. — Закон о изменама и допунама у Закону о заштити ауторског права [1931] — од објаве
4. јун 1946. — Закон о заштити ауторског права [1946] — од објаве, ретроактиван
28. август 1957. — Закон о ауторском праву[1957] — три месеца од објављивања, ретроактиван
24. јул 1968. — Закон о ауторском праву[1968] — двадесет дана од објављивања
14. јул 1978. — Закон о ауторском праву[1978] — три месеца од објављивања
15. мај 1998. — Закон о ауторском и сродним правима[1998] — осам дана од објављивања

Но, осим закона из 1946. године, сви они су трајање ауторских права одређивали на 50 година након смрти аутора (тј. 50 година од смрти последњег аутора, ако је у питању више аутора, или 50 година од издавања дела ако је аутор анониман или непознат, односно ако је дело издато од стране правног лица). [1946] је, са друге стране, ауторска права ограничио на животни век аутора, и животни век његове жене у случају његове смрти, те њихову децу до навршених 25 година старости (у нарочитим околностима и на родитеље и унуке): очигледна је намера да ауторска права обезбеде „зараду“ самим ауторима за живота и њиховој деци до завршетка школовања, тј. „осамостаљења“. Да не улазимо у то што би у случају смрти жене аутора, муж остао ускраћен за уживање ауторских права на њеним делима :-)

Ипак, у складу са међународним конвенцијама, то се враћа на уобичајени облик већ у [1957], и то „ретроактивно“: закон важи и на она дела чија су ауторска права законом [1946] можда истекла (нпр. аутори без супружника и потомака преминули до доношења закона 1957. пошто је и ранији био ретроактиван).

Законом из 1957. први пут се раздвајају морална и имовинска права аутора, док је важна промена у закону из 1998. године то што престаје да постоји правно лице као носилац ауторских права.

Важно је приметити и да су неки од горњих закона били и „ретроактивни“ — осим што су продужавали рокове и опсег заштите за дела чија заштита још није истекла (ја чак и то сматрам ретроактивним, али у правном речнику се изгледа тај израз другачије користи), такође су продужавали рокове и проширивали опсег заштите за дела којима би по ранијем закону заштита истекла, а по новом није.

Ауторска права у Србији у овом веку

Нови век доноси са собом и ново време. Живи се све брже, и ауторска дела имају све краћи рок „трајања“, а рок заштите ауторских дела је... све дужи.

Тако први закон о ауторским и сродним правима новог века у Србији (тј. Србији и Црној Гори), Закон о ауторским и сродним правима[2004] продужава трајање заштите на 70 година (од смрти аутора или од издавања ако је аутор непознат или правно лице). Новији, последњи Закон о ауторским и сродним правима[2009] не доноси значајне измене у погледу трајања основних ауторских права. Оба су ступила на снагу осам дана од објављивања у Службеном гласнику СЦГ, односно Србије.

Занимљиво, у изменама закона[2011] се враћа појам „колективног дела“ код којих ауторска права трају 70 година од објављивања (где су колективна дела она настала „спајањем већег броја прилога у једну целину“ одређена у [2009], а дати примери су енциклопедије, антологије, рачунарски програми, базе података).

Трајање ауторских права по законима

Закон	Аутор	Заштитни рок	Ретроактиван?
1929.	познат	50 год од смрти	да
1929.	непознат или правно лице	50 год од објављивања	да
1946.	није одређено	до смрти или смрти/преудаје супружника („жене“), односно до навршене 25. године ауторове деце	да
1957.	познат	50 год од смрти	да
1957.	непознат или правно лице	50 год од објављивања	да
1968.	познат	50 год од смрти	не
1968.	непознат или правно лице	50 год од објављивања	не
1978.	познат	50 год од смрти	не
1978.	непознат или правно лице	50 год од објављивања	не
1998.	познат	50 год од смрти	не
1998.	непознат	50 год од објављивања	не
2004.	познат	70 год од смрти	не
2004.	непознат	70 год од објављивања	не
2009.	познат	70 год од смрти	не
2009.	непознат	70 год од објављивања	не
2011.	колектив	70 год од објављивања	не

Шта више није заштићено?

Да бисмо утврдили шта од ауторских дела издатих у Србији више не подлеже заштити ауторских (имовинских) права, морамо узети неколико ствари у обзир:

Неки од закона су ретроактивни (важе и на дела чија су права можда истекла пре њиховог доношења)
Законски рок почиње да тече од 1. јануара наредне године од године у којој је ауторско дело издато
У случају познатих појединачних аутора, смрт оног који је најкасније умро одређује почетак тока заштитног рока, док у случају дела чији су „аутори“ правна лица или непознати (анонимни или под псеудонимом без познатог грађанског имена аутора)
Сваки закон је важио до дана који претходни дану ступања на снагу наредног закона

Закон	Објављен	Ступио на снагу	Важио до	Трајање заштите	Истекла заштита
[1895]	26. дец 1895.	26. дец 1895.	26. дец 1929.	30	31. дец 1898.
[1929]	27. дец 1929.	27. дец 1929.	03. јун 1946.	50	31. дец 1895.
[1946]	04. јун 1946.	04. јун 1946.	27. нов 1957.	0	27. нов 1957.
[1957]	28. авг 1957.	28. нов 1957.	12. авг 1968.	50	31. дец 1917.
[1968]	24. јул 1968.	13. авг 1968.	13. окт 1978.	50	31. дец 1927.
[1978]	14. јул 1978.	14. окт 1978.	22. мај 1998.	50	31. дец 1947.
[1998]	15. мај 1998.	23. мај 1998.	31. дец 2004.	50	31. дец 1953.
[2004]	24. дец 2004.	01. јан 2005.	18. дец 2009.	70	31. дец 1938.
[2009]	11. дец 2009.	19. дец 2009.	...	70	31. дец 1946.
[2011]	26. дец 2011.	03. јан 2012.	...	70	31. дец 1946.

Напомена: за дела објављена 1954. године, могуће је да су њихова права такође „истекла“. Пошто је [2004] почео да важи тек од 1. јануара 2005. то би сва дела чији је рок од 50 година почео да тече 1. јануара 1955. истекао до 31. децембра 2004. 23:59:59.9999... Но, пошто не знам какав је правни третман у овом граничном случају, ограничио сам се на оно што је сигурно истекло.

Најзначајнији су „масни“ датуми, те тако имовинска права више нису заштићена:

Свим делима чији су сви аутори преминули до 31. децембра 1953. године
Свим делима непознатих аутора (непотписаних или под псеудонимима за које се не знају грађанска имена) објављених до 31. децембра 1953. године
Свим делима објављених до 31. децембра 1947. године чији је носилац ауторских права правно лице

Значајно је приметити да, од продужења трајања заштите на 70 година [2004] ниједно ауторско дело није остало без заштите: почетком 2017. године, по актуелном закону, тек би дела објављена 1946. године постала слободна за употребу, односно, мораћемо сачекати још две године (до 2019.) да би се напокон нека нова дела нашла у „јавном власништву“, и то би се односило само на „колективна дела“ која изменама из [2011] уживају заштиту само од дана објаве, а не од смрти последњег аутора. За остала дела, мораћемо сачекати још додатних 5 година (почетак 2024.), па ће коначно и дела објављена 1954. године бити слободна за употребу.

Додатна појашењења

Ваљда је од почетка јасно да нисам правник, те да се овде записано мора узети са резервом. Шта год да радите што се тиче ауторских права, пре свега се обратите својој савести, а потом и неком правнику.

Пошто ме превасходно занима употребљивост давно објављених књижевних дела, нисам се дотицао оних врста ауторских дела на које у одређеним законима важе другачији рокови заштите (по правилу краћи, а ту нарочито спадају фотографије у старијим законима, односно базе података у новијим). На тај начин сам поједноставио анализу, али за сваку врсту грађе се, помоћу горње табеле и употребом истог обрачуна уз другачији рок може добити жељени резултат.

Повремено чак и текст поједностављујем тако што кажем само „од дана издавања“, а то може, у зависности од актуелног закона, значити разне ствари (нпр. „од дана издавања ако је издато за живота аутора, а иначе од дана његове смрти“; или, „од дана када је последњи наставак објављен“...). Ако сте у дилеми, не верујте ничему што пишем: нити сам правник, нити ћу прихватити одговорност за било какво туђе деловање на основу мог мишљења.

Библиографија

[1895] Gesetz, betreffend das Urheberrecht an Werken der bildenden Künste und der Photographie, 26. децембар 1895.
[1929] Закон о заштити ауторског права, Службене новине Краљевине Југославије, Година XI — 1929. број 304—CXXIX, 27. децембар, 1929.
[1931] Закон о изменама и допунама у Закону о заштити ауторског права од 26 децембра 1929 године, Службене новине Краљевине Југославије, Година XIII — 1931 — број 150, 6. јул 1931.
[1946] Закон о заштити ауторског права, Службени лист Федеративне Народне Републике Југославије, број 45, 4. јун 1946.
[1957] Закон о ауторском праву, Службени лист ФНРЈ, број 36, година XIII, 28. август 1957.
[1968] Закон о ауторском праву, Службени лист СФРЈ, број 30, година XXIV, 24. јул 1968.
[1978] Закон о ауторском праву, Службени лист СФРЈ, број 19/78 са допунама у 24/86 и 21/90, 14. јул 1978.
[1998] Закон о ауторском и сродним правима, Службени лист СРЈ, 24/98, 15. мај 1998.
[2004] Закон о ауторском и сродним правима, Службени лист СЦГ, 61/04, 24. децембар 2004.
[2009] Закон о ауторском и сродним правима, Службени гласник РС, 104/09, 11. децембар 2009.
[2011] Закон о изменама и допунама Закона о ауторском и сродним правима, Службени гласник РС, 99/11, 26. децембар 2011.

You don't have to pick your battles. You just need to accept losing.

(Oh yes, I know about the positive stance of "you should not accept losing", but if you believe in that, you haven't engaged in enough battles yet :)

Routing git clone over "dumb" HTTP?

Doing 'git clone' over either of git:// or http:// backed by git-http-backend results in big memory usage for big repositories (mostly in 'compressing objects' phase). This means that you can usually kill any git server hosting big repos by doing concurrent 'git clone' runs of those repos at the same time.

Instead of doing that, I'd like to keep benefits of the git-http-backend for all users except those using 'git clone'. Anyone has any ideas on how to do that?

OTOH, maybe I am looking for the wrong solution. git supposedly does mmap() of the pack files, and the only thing I need to do is ensure packs are suitably small so they could me "swapped-out" (which equals to being discarded from memory with mmaped files). Or, since git does a mmap() of uncompressed temporary file, maybe I can get git to store uncompressed data instead, allowing it to mmap them directly?

I wouldn't be surprised if I am entirely on the wrong track here. If anybody has ideas on what to do to run a git server with big repositories without needing gazilions of memory, please direct me in the comments section below.

intltool 0.50 released

So, with a few patches already in lp:intltool, I've had some time today to go through all the existing patches attached to bugs and see if I can get them into landable state.

The result is an intltool 0.50.0 release, which has a few reasonably sized changes.

The biggest changes are:

#580526: Finally, support for gsettings gschema.xml files is merged in, which should enable maintainers to get a slightly simpler build setup (i.e. no need to use NOMERGE rule anymore, and you can have intltool directly extract translations from .gschema.xml files).
#790574: Let xgettext extract Scheme strings out, and add support for intltool-update -m to find files with marked strings.
#806006: Improve handling of quotes in intltool-update -m so you get less (no?) warnings about mismatched quotes, and Python processing doesn't get messed up with docstrings and similar.
#520986: one for the translators—messages are extracted in the order they appear in original files now, thus allowing translators to infer more of the context from the ordering.

There are a few other bug fixes, but listed above are those with the highest risk factor. Please test and file bugs!