A general comment would be that the execution time of a given Gcode file is a complex combination of a lot of parameters plus , potentially, the performance of the Gcode delivery link. For example, Chilipeppr was initially developed to focus on keeping the motion planner as busy as possible and is buffer fill managed. G code delivered by UGS or CoolTerm might not run as fast.
Most folks on this forum think in terms of XYZ CNC machines. Are you, or perhaps are you working on a complex motion robot?
Can you bound your need for time estimation?
A simple bound might be “How long can I walk away from the machine while the job runs”
A complex bound might be a system that dynamically generates Gcode to compensate for motion that has just occurred.
And, by the way, some Gcode might run a little faster on G2core than on tinyG because the compute engine has more horsepower, depending on the complexity of the effective tool path.
What are you designing around?