Move some hint logic to compile_hint

[JulianGCalderon]

Currently compile_hint barely contains any logic.

cairo-vm/vm/src/hint_processor/hint_processor_definition.rs

Lines 33 to 52 in 065c8f4

	fn compile_hint(
	&self,
	//Block of hint code as String
	hint_code: &str,
	//Ap Tracking Data corresponding to the Hint
	ap_tracking_data: &ApTracking,
	//Map from variable name to reference id number
	//(may contain other variables aside from those used by the hint)
	reference_ids: &HashMap<String, usize>,
	//List of all references (key corresponds to element of the previous dictionary)
	references: &[HintReference],
	// Identifiers stored in the hint's program.
	constants: Rc<HashMap<String, Felt252>>,
	) -> Result<Box<dyn Any>, VirtualMachineError> {
	Ok(any_box!(HintProcessorData {
	code: hint_code.to_string(),
	ap_tracking: ap_tracking_data.clone(),
	ids_data: get_ids_data(reference_ids, references)?,
	constants,
	}))

We should investigate if there is logic that can be moved to the compilation step. The idea is to properly take advantage of compile_hint/execute_hint, instead of using compile_hint as a placeholder.

Some ideas:

• All references are computed, regardless of whether they are used or not. This accounts for 7% of the execution
• When executing a hint, we need to match the hint code. The match is really big, which could affect performance.
• Constant lookup is being done on execution, but could be moved to compilation.

[DiegoCivi]

Regarding the second point:

When executing a hint, we need to match the hint code. The match is really big, which could affect performance.

I moved the match from execute_hint() to compile_hint() and benchmarked blocks 20000 to 20010 which have more cairo0 code than recent blocks. But it showed no performance changes. This change mainly affects contracts that call multiple times the same hint so I also added 2 cairo programs (here and here) that call the same hint multiple times, benchmarked them and again there was no improvement in performance. All this changes can be see in #2224

[DiegoCivi]

For the last point:

Constant lookup is being done on execution, but could be moved to compilation.

When a hint wants to get a constant from its name we iter the hashmap containing every constant:

pub fn get_constant_from_var_name<'a>(
    var_name: &'static str,
    constants: &'a HashMap<String, Felt252>,
) -> Result<&'a Felt252, HintError> {
    constants
        .iter()
        .find(|(k, _)| k.rsplit('.').next() == Some(var_name))
        .map(|(_, n)| n)
        .ok_or_else(|| HintError::MissingConstant(Box::new(var_name)))
}

To make proper use of the hashmap I changed it to have only the constants names as keys. So instead of having scope1.scope2.CONST_NAME we have CONST_NAME. So before compiling the hints and creating the HintProcessorData, we modify the constants hashmap:

    pub fn get_hint_data(
        &self,
        references: &[HintReference],
        hint_executor: &mut dyn HintProcessor,
    ) -> Result<Vec<Box<dyn Any>>, VirtualMachineError> {
        let mut constants = HashMap::new();
        for (k, v) in &self.program.constants {
            let new_k = k.rsplit(".").next().unwrap().to_string();
            constants.insert(new_k, v.clone());
        }

        let constants = Rc::new(constants);
        ...
}

So then we can get the hashmaps like this:

pub fn get_constant_from_var_name<'a>(
    var_name: &'static str,
    constants: &'a HashMap<String, Felt252>,
) -> Result<&'a Felt252, HintError> {
    // constants
    //     .iter()
    //     .find(|(k, _)| k.rsplit('.').next() == Some(var_name))
    //     .map(|(_, n)| n)
    //     .ok_or_else(|| HintError::MissingConstant(Box::new(var_name)))
    constants
        .get(var_name)
        .ok_or_else(|| HintError::MissingConstant(Box::new(var_name)))
}

However this didn't show any important improvements.

Benchmarks

This were executed on an AMD Ryzen 9 with 125 gb of memory

	blocks 20000 to 20010	blocks 2000000 to 2000010
v2.5.0	7633702396 ns ( 7.63 s )	5782546067 ns ( 5.78 s )
branch with optimization	7559605951 ns ( 7.56 s )	5565264011 ns ( 5.56 s )

We can see that for blocks 20000-20010 (mainly cairo0) there was only an improvement of 0.9%. And in the case of blocks 2000000-2000010 there was only an improvement of 4%