Cacheování KaTeXu #58

Open
opened 4 weeks ago by jan · 7 comments
jan commented 4 weeks ago

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?

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?
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.
Collaborator

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é.
Collaborator

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ě.
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 4 weeks ago
Poster

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.
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`.
Collaborator

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ě.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.