Cacheování KaTeXu

jan commented

2024-04-07 13:31:30 +02:00

Member

Docela mě inspirovalo @jancerny projekt, kde kešuje všechno, co se předhazuje KaTeXu a tím o hodně zrychluje buildy. Přijde mi, že by bylo velmi hezké tohle implementovat i do formátítka, tam nám do toho ale hází vidle to, že jednotlivé bloky mezi sebou udržují nějaký stav – pokud si v jednom bloku definuji makro, bude použitelné v jiném. To jsem implementoval primárně proto, aby to pak bylo konzistentní s TeXovým výstupem, protože tam to tak reálně bude fungovat.

IMO máme několik možností, buď

Nechat si magii na udržování stavu s tím, že bude katexátko po socketu kromě vyrenderovaného HTML vracet také nějaký hash tohohle stavu, podle kterého bude možné kešovat (místo kešování formule budeme kešovat dvojici formule-hash). Pokud předpokládáme, že měnení stavu je spíše vzácnost, tohle bude pořád příjemné zrychlení.
Zařídit, že stav se musí měnit explicitně – pokud chci ve formuli definovat makro, musím tu formuli nějak označit. To může buď znevalidovat cache, nebo také předávat nějaké hashe jako výše
Umožnit měnit stav jen v nějaké speciální preambuli na začátku a celou magii na udržování stavu v katexu dát pryč. Pak to půjde kešovat hezky.

U bodů 2) a 3) by mi dávalo smysl zařídit konzistenci s TeXem tak, že budeme formule balit do {}, (což pořád nezamezí gdefům, ale pokud se někdo chce střílet explicitně do nohy, ať si poslouží)

Velmi si nejsem jist, co je pro nás nejlepší varianta. Thoughts?

Docela mě inspirovalo @jancerny projekt, kde kešuje všechno, co se předhazuje KaTeXu a tím o hodně zrychluje buildy. Přijde mi, že by bylo velmi hezké tohle implementovat i do formátítka, tam nám do toho ale hází vidle to, že jednotlivé bloky mezi sebou udržují nějaký stav – pokud si v jednom bloku definuji makro, bude použitelné v jiném. To jsem implementoval primárně proto, aby to pak bylo konzistentní s TeXovým výstupem, protože tam to tak reálně bude fungovat. IMO máme několik možností, buď 1) Nechat si magii na udržování stavu s tím, že bude katexátko po socketu kromě vyrenderovaného HTML vracet také nějaký hash tohohle stavu, podle kterého bude možné kešovat (místo kešování formule budeme kešovat dvojici formule-hash). Pokud předpokládáme, že měnení stavu je spíše vzácnost, tohle bude pořád příjemné zrychlení. 2) Zařídit, že stav se musí měnit explicitně – pokud chci ve formuli definovat makro, musím tu formuli nějak označit. To může buď znevalidovat cache, nebo také předávat nějaké hashe jako výše 3) Umožnit měnit stav jen v nějaké speciální preambuli na začátku a celou magii na udržování stavu v katexu dát pryč. Pak to půjde kešovat hezky. U bodů 2) a 3) by mi dávalo smysl zařídit konzistenci s TeXem tak, že budeme formule balit do {}, (což pořád nezamezí gdefům, ale pokud se někdo chce střílet explicitně do nohy, ať si poslouží) Velmi si nejsem jist, co je pro nás nejlepší varianta. Thoughts?

jirikalvoda commented

2024-04-08 18:40:08 +02:00

Owner

Ha, tady už řešíš moji připomínku z #59.

Tak další iterace:

No momentálně zajistit funkční \def mezi LuaTeXem a KaTeXem moc nefunguje.
K TaTexu potřebuješ definici obalit do dolárků a v LuaTeXu nikoliv.

Osobně bych se tedy klanil k tomu, že prostě zavademe nějaký speciální způsob definic pro TeX (asi jako code block) a ten se pak bude cachovat pro vše následující.
gdef budiž střelou do nohy.

Ha, tady už řešíš moji připomínku z #59. Tak další iterace: No momentálně zajistit funkční \def mezi LuaTeXem a KaTeXem moc nefunguje. K TaTexu potřebuješ definici obalit do dolárků a v LuaTeXu nikoliv. Osobně bych se tedy klanil k tomu, že prostě zavademe nějaký speciální způsob definic pro TeX (asi jako code block) a ten se pak bude cachovat pro vše následující. `gdef` budiž střelou do nohy.

jancerny commented

2024-04-08 19:24:36 +02:00

Member

Co cachovat po kusech, kdy jeden kus je scope maker. Předpokládám, že scope bude omezený na soubor. Pokud se stane změna v katexu ve tom scopu, tak celý cachovaný kus zahodím, vygeneruju znovu a pak uložím do cache.

Podle mě i takto to bude výrazně rychlejší, protože změny se typickou dělat blízko sebe a v kontextu celé webu budou spíš malé.

Co cachovat po kusech, kdy jeden kus je scope maker. Předpokládám, že scope bude omezený na soubor. Pokud se stane změna v katexu ve tom scopu, tak celý cachovaný kus zahodím, vygeneruju znovu a pak uložím do cache. Podle mě i takto to bude výrazně rychlejší, protože změny se typickou dělat blízko sebe a v kontextu celé webu budou spíš malé.

jancerny commented

2024-04-08 23:33:55 +02:00

Member

Osobně bych se tedy klanil k tomu, že prostě zavademe nějaký speciální způsob definic pro TeX (asi jako code block) a ten se pak bude cachovat pro vše následující.
gdef budiž střelou do nohy.

Co třeba vynutit, že makra jsou pro celý web globálně definovaná ? Tak bude snadné sledovat jejich změnu a nebudou nikde duplicitně.

> Osobně bych se tedy klanil k tomu, že prostě zavademe nějaký speciální způsob definic pro TeX (asi jako code block) a ten se pak bude cachovat pro vše následující. > `gdef` budiž střelou do nohy. Co třeba vynutit, že makra jsou pro celý web globálně definovaná ? Tak bude snadné sledovat jejich změnu a nebudou nikde duplicitně.

jirikalvoda commented

2024-04-08 23:37:17 +02:00

Owner

Co třeba vynutit, že makra jsou pro celý web globálně definovaná ? Tak bude snadné sledovat jejich změnu a nebudou nikde duplicitně.

To mi připadá už trošku moc omezující. I aktuální TeX umí jednoduchý \cdef.

Navíc nezapomínej, že formátítko není jan KSPí web, takže by se hodilo aspoň o trošku obecnější řešení.

Ale určitě nevidim problém říct, že při změně maker přefenerováváme (skoro) vše.

> Co třeba vynutit, že makra jsou pro celý web globálně definovaná ? Tak bude snadné sledovat jejich změnu a nebudou nikde duplicitně. To mi připadá už trošku moc omezující. I aktuální TeX umí jednoduchý `\cdef`. Navíc nezapomínej, že formátítko není jan KSPí web, takže by se hodilo aspoň o trošku obecnější řešení. Ale určitě nevidim problém říct, že při změně maker přefenerováváme (skoro) vše.

jan commented

2024-04-08 23:42:12 +02:00

Author

Member

A co ta první možnost, co jsem navrhoval? Pak to bude fungovat úplně stejně, jako to funguje teď, akorát se do klíče keše zanamenávat i stav maker. Když se stav maker nebude měnit, keše budou furt validní a pokud se změní, použije se jiná keš.

No momentálně zajistit funkční \def mezi LuaTeXem a KaTeXem moc nefunguje.
K TaTexu potřebuješ definici obalit do dolárků a v LuaTeXu nikoliv.

Nechápu, kam tím míříš. Když napíšeš do normálního markdownového textu nějaký náhodný \def, vyescapuje se a do TeXu se nedostane. Pokud použiješ RawBlock, ten už se do TeXu dostane, ale očekávatelně v KaTeXu nemá co dělat, protože s ním nemá nic společného. Jediné, kde se mohou vyskytovat TeXová makra na dvou různých místech je právě matematika.

A co ta první možnost, co jsem navrhoval? Pak to bude fungovat úplně stejně, jako to funguje teď, akorát se do klíče keše zanamenávat i stav maker. Když se stav maker nebude měnit, keše budou furt validní a pokud se změní, použije se jiná keš. > No momentálně zajistit funkční \def mezi LuaTeXem a KaTeXem moc nefunguje. > K TaTexu potřebuješ definici obalit do dolárků a v LuaTeXu nikoliv. Nechápu, kam tím míříš. Když napíšeš do normálního markdownového textu nějaký náhodný `\def`, vyescapuje se a do TeXu se nedostane. Pokud použiješ RawBlock, ten už se do TeXu dostane, ale očekávatelně v KaTeXu nemá co dělat, protože s ním nemá nic společného. Jediné, kde se mohou vyskytovat TeXová makra na dvou různých místech je právě matematika.

jirikalvoda commented

2024-04-08 23:45:21 +02:00

Owner

V luaTeXu ale def v matematice nefunguje. Je to oddělený kontext.

\def\a{a}
$\def\a{b}$

$\a$
\bye

Vypíše a.

V luaTeXu ale def v matematice nefunguje. Je to oddělený kontext. ``` \def\a{a} $\def\a{b}$ $\a$ \bye ``` Vypíše `a`.

jancerny commented

2024-04-09 16:38:13 +02:00

Member

A co ta první možnost, co jsem navrhoval? Pak to bude fungovat úplně stejně, jako to funguje teď, akorát se do klíče keše zanamenávat i stav maker. Když se stav maker nebude měnit, keše budou furt validní a pokud se změní, použije se jiná keš.

Jak na to koukám, tak asi s tebou souhlasím. Přikláním se k první variantě.

> A co ta první možnost, co jsem navrhoval? Pak to bude fungovat úplně stejně, jako to funguje teď, akorát se do klíče keše zanamenávat i stav maker. Když se stav maker nebude měnit, keše budou furt validní a pokud se změní, použije se jiná keš. Jak na to koukám, tak asi s tebou souhlasím. Přikláním se k první variantě.

Cacheování KaTeXu #58