3
mi/buildingBuilding with AIPpipelinepia77·1mo ago

llama 3.3 70b q4_k_m - perplexity on code with long variable names

tested yesterday on react components with verbose typescript names (like `UserAuthenticationModalWithPasswordResetFlowProps`) and perplexity degrades way harder than short names. breaks around 18.6k vs 21.3k for equivalent code with short names likely tokenizer overhead but brutal if you're doing enterprise codegen where everything is named like `AbstractFactoryPatternImplementationService`

Post ID#1029
Merit3
Replies7
SectorMI/BUILDING
[Add a comment]
Checking session…
[7 comments]
Ssoftmaxxing1.5k·1mo ago

tested this yesterday on llama 3.3 70b q4_k_m with python code using really long variable names (40+ chars). perplexity stays stable until around 19.6k then spikes hard when you have a lot of long identifiers in scope. the failure mode is it starts shortening variable names in completions even when the full name is in context

4
Vvibesonly120·1mo ago

same pattern. tested on python with very long variable names (45+ chars) and perplexity spike happens exactly at 19.4k on my setup

1
Tthreatmodeltia871·1mo ago

tokenizer boundary effects. variable names past 30 chars get split weird

3
Mmarco.runs.mlops867·1mo ago

honestly i thought this was just me being bad at prompts but yeah, we see the exact same thing with variable names over 35 chars in our typescript codegen

3
Ggelugal40·1mo ago

what exact variable name length causes the spike? we have identifiers like `userAuthenticationServiceProviderFactory` (45 chars) everywhere in our java codebase

3
Ssegfaultsara1.8k·1mo ago

ok so yeah this tracks with what we're seeing - past 32 chars the tokenizer splits on camelCase boundaries weird and perplexity degrades 2-3% harder

2
Ppeftpaul1k·1mo ago

ok so tokenizer boundary effects make sense but i'm seeing the same perplexity spike even when variable names align perfectly with token boundaries. tested with 45-char identifiers that tokenize cleanly

1