bump up limits even further
my VPS has 8 gigabytes of RAM. it's not exactly out of the question to buy a larger one, and in the future we could just, y'know, not preallocate _all_ the memory, and instead reallocate if a certain threshold is reached
This commit is contained in:
parent
d309211558
commit
a35ac17b86
|
@ -70,14 +70,14 @@ max_chunks = 2
|
||||||
max_defs = 256
|
max_defs = 256
|
||||||
|
|
||||||
# Maximum amount of tokens a single chunk can have.
|
# Maximum amount of tokens a single chunk can have.
|
||||||
max_tokens = 4096
|
max_tokens = 65536
|
||||||
|
|
||||||
# Maximum amount of events that the parser may emit in a single chunk.
|
# Maximum amount of events that the parser may emit in a single chunk.
|
||||||
# These don't take up that much memory (a byte per event), so having many of these isn't a big deal.
|
# These don't take up that much memory (a byte per event), so having many of these isn't a big deal.
|
||||||
max_parser_events = 65536
|
max_parser_events = 65536
|
||||||
|
|
||||||
# Maximum amount of AST nodes in a single parse.
|
# Maximum amount of AST nodes in a single parse.
|
||||||
ast_capacity = 4096
|
ast_capacity = 65536
|
||||||
|
|
||||||
# Maximum size of a bytecode chunk.
|
# Maximum size of a bytecode chunk.
|
||||||
# This must be <= 65536 due to bytecode limitations - offsets are stored as 16-bit integers.
|
# This must be <= 65536 due to bytecode limitations - offsets are stored as 16-bit integers.
|
||||||
|
|
Loading…
Reference in a new issue