## 3 Results
### Energy  
Efficiency, measured via Floating-point Operations Per Second (FLOPS), fluctuates widely, spanning several orders of magnitude and clearly distinguishing models by computational complexity. The observed disparity indicates the need to consider trade-offs between predictive capability and resource constraints during model selection. Such metrics underline the practical considerations surrounding algorithm selection for deployment in diverse computational environments. Moreover, the power consumption metrics distinctly display varied capacity among the tested models. Specific patterns emerge, where Regularized Discriminant Analysis achieves the pinnacle in Percentage CPU usage, while MultiSURF occupies the lowest tier. LSTM-based models deliberately settle within intermediate ranges, suggesting Idiosyncratic interactions between model complexity and computational requisites. Observations of computational performance parameters indicated multiple efficiency findings. Extended evaluation involved Total Memory (TM), referencing system-wide usage, Free Memory (FM) that remains available during processes, Used Memory (UM), Percentage Memory (PM), Percentage CPU (PC), along with FLOPS. Such measurements originated directly from physical hardware counters. Bursting from device-based readouts, these metrics captured real-time resource consumption without additional interpolation. If the label indicates CPU vs GPU, that device was employed for training; in situations lacking that specification, system RAM usage is implied. This scheme preserved memory tracking for both hardware configurations. TM signified total system memory, FM signified unoccupied memory, whereas UM reflected allocated memory. That same premise applied to memory usage percentages, in addition to GPU-based allocation tracking. Distinctions were noted in FM, UM, PM, and PC, together with FLOPS, culminating in unique computational efficiency patterns. Meanwhile, TM maintained consistency across distinct implementations. With VGG models, we observed unexpected energy usage spikes for the CNN portion. For validation, there was an instant detach step to maintain accurate metric recordings. The numerical tableau presented within Table 6 partitions the evaluated learning mechanisms into upper-tier entities. Within each tier, five statistics appear: Free Memory (FM), Used Memory (UM), Percentage Memory (PM), Percentage CPU (PC), and Floating-Point Operations per Second (FLOPS). Terminological compression will henceforth label this sextet as the Metric Hexad (MH). TM gauges correctly resolved instances; FM tabulates erroneous resolutions; UM quantifies trials yielding indeterminate state; PM reflects resilience beneath metric permutation; PC expresses mean percentage of computational resource occupancy; FLOPS conveys arithmetic throughput magnitude. Each value stems directly from empirical logging executed at identical hardware baselines; hence, cross-algorithm comparability remains intact. Precision regarding unit conversion was maintained via double-precision counters, mitigating quantization drift. Inspection of the upper echelon, comprising RNN, Stacking, AdaBoost, and Random Forest, together with RNN (GPU), reveals FM values spanning 2.08-4.42. That clustering implies penetrative correctness uniformity. UM spans 29.97-31.86. PM extends from 48.95 to 52.85, corresponding to misclassification drift below one-tenth of a percent relative to FM magnitude, a tolerable deviation given dataset complexity. PC oscillates markedly between 14.22 and 49.63. Arithmetic intensity quantified via FLOPS positions Stacking, AdaBoost, and Random Forest at \(2.11\times 10^{15}\), whereas RNN and RNN (GPU) record \(1.83\times 10^{9}\) and \(6.58\times 10^{7}\), respectively. When FM, UM, PM, and PC, together with FLOPS, coalesce,RNN delivers balanced correctness yet imposes a moderate arithmetic burden, whereas RNN (GPU) supplies the lightest resource profile. Transition toward the lower echelon--KNN, RBM, GaussianNB, Gradient_Boost, and AdaBoost--reveals nuanced behavior.