You'd be wise to completely refactor the code and to separate the logic for parsing and processing.

ATM this is a maintenance nightmare (sorry)

parser

This "format" seems to have a strict grammar:

• lines have <indentation> <capitalized KEYWORD > <datafields>
• the <datafields> are either space separated or {grouped by curlies}
• if lines are nested the level is finished by END_keyword

So write a _generic_ parser (and better implicitly check for correctness) by

• parsing each line with a regex,
• keeping record of nesting levels
• putting parsed data into a hash of hashes

If this parser works correctly you can start measuring the _speed_ for your huge file.

Now you are able to tell if the DB operations are the bottleneck (most likely they are)

processing

You should try to bundle many DB-operations, cause there is always a overhead.

If the complete HoH after parsing the whole file is to large, you must define "rules" which hook into the parsing.

This can be done by checking after each line for suitable callbacks to evaluate your temporary data so far.

Define a callback-hash $action{KEYWORD} holding subs to be called if a keyword is processed.

HTH! :)