Computer code execution operations quantification method and system

Abstract

Quantifying computational resource consumption without executing computing operations by incorporating workload factors including workload parameters, input / configuration parameters, code line execution probability and scale points the number of computing operations required to execute a given set of instructions is determinable, enabling deterministic assessment of actual execution requirements, identification of inefficient computations and estimation of execution resources and costs across various computing environments, including cloud, physical, and hybrid systems.

Description

[0001] COMPUTER CODE EXECUTION OPERATIONS QUANTIFICATION METHOD

[0002] AND SYSTEM

[0003] FIELD OF INVENTION

[0004] The present disclosure relates to the quantification of computing operations, and in particular to a method and system for quantifying and calculating execution operations requirements and costs based on the deterministic nature of computer operations.

[0005] BACKGROUND OF INVENTION

[0006] Computational performance refers to how quickly and effectively a system completes tasks, typically measured by execution time, response time, and latency. However, high performance does not necessarily correlate with optimal resource consumption; a system may achieve rapid execution while still performing excessive or redundant computations. This leads to computational waste, which encompasses operations that consume processing power, memory, or other resources without contributing to meaningful output. While waste may not always degrade performance - particularly in environments with abundant computational capacity - it increases operational costs and system strain. Computational efficiency reflects the extent to which resources are utilized optimally to achieve a desired output with minimal waste.

[0007] The increasing complexity of modem computing environments presents significant challenges in optimizing software performance and managing computational resources efficiently. Suboptimal code - such as excessive computations, redundant operations, or inefficient memory and I / O handling - can result in unnecessary CPU cycles, memory usage, and network activity. For enterprises operating large-scale distributed systems, even small code inefficiencies can accumulate into substantial financial and operational overhead.

[0008] Extant profiling tools identify performance bottlenecks by analyzing runtime behavior with respect to numerous metrics including, inter alia, the time taken to execute a function, CPU time utilization, memory allocation, input / output (I / O) operations, and resource utilization. However, in computing environments with abundant resources, code inefficiencies may not cause noticeable slowdowns and therefore remain undetected by traditional profiling methods. Since profiling tools primarily assess performance and user experience rather than computational waste, excessive computations may not be detected if they do not impact performance.

[0009] Profiling tools are limited by their reliance on observed runtime behavior; they can only analyze performance during execution on a particular system. Because they assess system performance based on real-time conditions rather than the intrinsic computational requirements of the code, they cannot predict or prevent future performance issues. Thus, profiling results are tied to the specific hardware, software environment, and workload conditions under which the analysis is performed. While profiling tools provide insights into response time, latency, and CPU utilization, they do not indicate how the same code will perform under different system configurations or workloads, nor whether a given system is operating close to its fundamental computational limits. Modern computing systems do not degrade linearly. Software may appear to function optimally until a critical threshold is reached, at which point performance may deteriorate rapidly or the system may crash without warning. Profiling cannot predict these inflection points, as it only reflects current conditions.

[0010] Static analysis represents another approach to evaluating code, relying on examination of source code without execution to detect code quality issues, including functional issues, security issues and basic inefficiencies such as excessive nesting, loop-based inefficiencies, unreleased objects, missing DB indexes, duplicate code and unreachable code. However, static analysis techniques are not designed to identify or quantify computational waste. Traditional static analysis tools evaluate code quality based on structure and complexity metrics but not for the purpose of computational waste reduction.

[0011] Static analysis tools, such as CodeScene™, assess code health by analyzing how frequently and extensively code is modified over time, identifying areas with high change rates as potential sources of technical debt - code that may be poorly designed, difficult to update, or prone to future issues. These tools focus on structural weaknesses in the code as opposed to measuring the actual computational cost of executing the code. While static analysis tools can highlight basic inefficiencies, they cannot measure the actual computational cost of executing the code, nor do they provide an evaluation of wasted CPU cycles, memory usage, or I / O operations. Further, traditional static code analysis tools are scope-oriented and not context-based, thus they assess individual code snippets in isolation. As a result, for example, they may suggest local optimizations without recognizing that an entire operation is redundant when considered in a broader context.

[0012] A fundamental principle of traditional computing is deterministic execution, wherein a given set of input data and instructions results in the same sequence and number of operations, ultimately producing the same output. The instructions executed by a computer are represented in machine language, which is directly interpretable by the hardware. These machine instructions are generated through compilation or interpretation, wherein a compiler or interpreter translates code written in a high-level programming language into machine language. The process of translation from a programming language to machine language is also deterministic meaning that a given source code or script will always be converted into the same set of machine instructions when processed by the same compiler or interpreter.

[0013] Given the deterministic nature of both computation and translation, the total number of computing operations required to execute a given set of instructions can, in principle, be determined without actual execution. Since machine instructions follow a fixed sequence dictated by the source code and compiler / interpreter translation, it is possible to analyze a program’ s computational workload by evaluating its structure at a fundamental level. This provides a direct means to quantify resource consumption for a given workload.

[0014] Despite the deterministic nature of computation and code translation, existing methodologies fail to leverage this property for preemptive computational cost analysis. Consequently, no current solution deterministically calculates the computational workload of a program across all levels of the computing stack.

[0015] There is thus a need in the art for a system that determines the number of computing operations required for program execution without necessitating execution. Such a system should leverage the deterministic nature of code execution to calculate computational requirements across all levels of the computing stack.

[0016] SUMMARY OF INVENTION

[0017] The following embodiments and aspects thereof are described and illustrated in conjunction with systems, devices and methods which are meant to be exemplary and illustrative and not limiting in scope. In various embodiments, one or more of the abovedescribed problems have been reduced or eliminated.

[0018] By incorporating workload factors including workload parameters, input / configuration parameters, code line execution probability and scale points, the number of computing operations required to execute a given set of instructions can be determined in advance, without executing the program. This applies to both physical and virtual computing environments, including cloud-based systems.

[0019] As machine code execution follows a deterministic process, the number of computing operations required to execute a given set of instructions can be determined in advance without execution, thereby providing a quantitative assessment of execution requirements and a cost estimations which may enable various efficiency driven operations and / or waste cancellation or prevention measures. Accordingly, a method and system for calculating the total number of computing operations required to execute machine language instructions over time on a computer or virtual computing environment, is presented.

[0020] The present invention provides a method and system for quantifying computational resource consumption without executing computing operations. This enables deterministic assessment of execution requirements, identification of inefficient computations and estimation of execution costs across various computing environments, including cloud, physical, and hybrid systems.

[0021] According to a first aspect of the invention, a method is provided for computational resource consumption management. The method comprises:

[0022] • Obtaining a scope of code comprising at least one code snippet.

[0023] • Associating a resource consumption representation for each line of code within the scope of code.

[0024] • Applying a computational cost process to determine the total number of computing operations required for execution without actual execution.

[0025] According to another aspect, the computational cost process includes the application of workload factors. According to another aspect, the computational cost process accounts for: a) The number of CPU operations, including: ALU operations, register write / read / shift / scan / delete operations, context switching, bus access / requests / waits and LI, L2 and L3 cache write / read / scan / delete; b) The number of RAM operations, including: allocation / deallocation overhead, write / read / scan / delete / flush and linked list overhead due to memory fragmentation; c) The number of disk operations, including: write / read / scan / delete fragmentation overhead, locks and waits, cluster size and swap file access; d) The number of network operations, including: initialization, authorization, pings, establishing a new connection, requesting a new connection from a connection pool, allocation waits, message transmitting, parity checks, packet size, protocol compression / decompression and packet validation; and e) The number of operating system operations, including: grant access requests, permission checks, locks and waits.

[0026] According to another aspect, the computational cost process output determines the computational stress imposed on a computing environment based on the total number of computing operations required for execution.

[0027] According to another aspect, computational stress can be calculated by using a computational cost output derived from code execution. According to another aspect, the determined computational stress can be classified into predefined effort levels based on available system resources.

[0028] According to another aspect, execution feasibility can be determined based on the determined effort level.

[0029] According to another aspect, the computational cost process output can be presented in any currency.

[0030] According to another aspect, the computational cost process detects and quantifies inefficient computing operations.

[0031] According to another aspect, the computational cost process estimates the currency-based cost for code execution.

[0032] According to another aspect, the computational cost process accounts for central processing unit (CPU) operations.

[0033] According to another aspect, the computational cost process accounts for random access memory (RAM) operations.

[0034] According to another aspect, the computational cost process accounts for disk operations.

[0035] According to another aspect, the computational cost process accounts for network operations. According to another aspect, the computational cost process identified high resource consuming code within a scope of code.

[0036] According to another aspect, the computational cost process identifies wasteful code segments within the scope of code.

[0037] According to another aspect, the computational cost process is operated upon pre-generated code permutations, thereby enabling the determination of an optimal code permutation.

[0038] According to another aspect, an LLM generates said pre-generated code permutations.

[0039] According to another aspect, pre-generated code permutations are generated manually.

[0040] According to another aspect, the output of the computational cost process is presented as a benchmark.

[0041] According to another aspect, the computational cost process is applicable across all computing systems, including cloud, physical and hybrid.

[0042] According to another aspect, the computational cost formula determines the percentage of available computational resources consumed by the scope of code.

[0043] According to another aspect, the computational cost process incorporates execution frequency. According to another aspect, the computational cost process incorporates concurrent execution factors.

[0044] According to another aspect, the computational cost process incorporates code line execution probabilities.

[0045] According to another aspect, the computational cost process incorporates external dependencies.

[0046] According to another aspect, the computational cost process estimates the execution cost of a workload across all computing systems such as cloud, physical, and hybrid, etc.

[0047] According to another aspect, a system for code -based computation resource consumption management is provided comprising at least one CPU, at least one memory storage means, at least on I / O operator, and optionally a network access means.

[0048] According to another aspect, the code -based computation resource consumption management system is configured to obtain a scope of code comprising at least one code snippet; associate resource consumption representation for each line of code within said scope of code and apply a computational cost process to determine the total number of computing operations required for execution of said scope of code. According to another aspect, the code -based computation resource consumption management system is applied without executing computing operations.

[0049] BRIEF DESCRIPTION OF THE FIGURES

[0050] Some embodiments of the invention are described herein with reference to the accompanying figures. The description, together with the figures, makes apparent to a person having ordinary skill in the art how some embodiments may be practiced. The figures are for the purpose of illustrative description and no attempt is made to show structural details of an embodiment in more detail than is necessary for a fundamental understanding of the invention.

[0051] In the Figures:

[0052] FIG. 1 constitutes a schematic of a code cost vision engine workflow, according to some embodiments of the invention.

[0053] FIG. 2 constitutes a schematic of a code cost vision engine, according to some embodiments of the invention.

[0054] FIG. 3 constitutes a schematic of a code stress vision workflow, according to some embodiments of the invention.

[0055] FIG. 4 constitutes a schematic of a code stress vision engine, according to some embodiments of the invention.

[0056] FIG. 5 constitutes a schematic of a legacy code analysis workflow, according to some embodiments of the invention. FIG. 6 constitutes a schematic of a new development analysis workflow with identified ICP, according to some embodiments of the invention.

[0057] FIG.7 constitutes a schematic of a new development analysis workflow without identified inefficient code pattern (ICP), according to some embodiments of the invention.

[0058] FIG.8 constitutes a schematic of a code permutation assessment engine workflow, according to some embodiments of the invention.

[0059] FIG. 9 constitutes a schematic of an example system architecture, according to some embodiments of the invention.

[0060] DETAILED DESCRIPTION OF SOME EMBODIMENTS

[0061] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and / or circuits have not been described in detail so as not to obscure the invention. Some features or elements described with respect to one embodiment may be combined with features or elements described with respect to other embodiments. For the sake of clarity, discussion of same or similar features or elements may not be repeated.

[0062] For purposes of this disclosure, the following terms shall have the meanings set forth below unless explicitly stated otherwise. Computational Performance: The speed and responsiveness of a system in executing tasks, typically measured through execution time, latency, and throughput. A system with high computational performance can complete operations quickly, but this does not necessarily indicate efficient resource usage. Performance can remain high even in the presence of excessive computations or redundant processes, particularly in environments with abundant computing resources.

[0063] Computational Efficiency: a measure of how effectively a system utilizes CPU, memory, storage, and network resources to perform computations. Computational efficiency evaluates how well resources are managed relative to the work performed.

[0064] Computational Waste: Unnecessary operations that consume computing resources without contributing to meaningful output. Examples include redundant calculations, excessive memory allocation, inefficient I / O operations, unnecessary API calls and data retrieving or transmitting.

[0065] Deterministic Execution: A property of computing wherein a given set of input data and instructions results in the same sequence of operations and produces the same output each time it is executed. This predictability enables computational cost estimation without actual execution.

[0066] Computational Stress: A measurement of the strain imposed on a computing environment by a given workload. Computational stress is determined by analyzing resource consumption in relation to system capacity, assessing how different components - such as the CPU, memory, disk, and network - respond under load. Excessive computational stress can lead to performance degradation, increased latency, overheating, hardware failure or increased operational cost. The impact on each component includes:

[0067] • CPU Stress: High computational load increases CPU utilization, potentially leading to thermal throttling, reduced processing efficiency, and longer execution times. Extreme CPU stress can cause system instability, increased power consumption, and premature hardware degradation.

[0068] • Memory Stress: Excessive memory allocation can lead to reduced system responsiveness. If available RAM is exhausted, the system may resort to slow diskbased swap memory, significantly impacting performance.

[0069] • Disk Stress: Heavy read / write operations may result in high RO latency, increased fragmentation, and reduced disk lifespan due to excessive wear.

[0070] • Network Stress: Intensive network operations can result in bandwidth congestion and high transmission latency. Under extreme conditions, network saturation may lead to dropped connections and dried pools, thereby affecting application performance and stability.

[0071] • Operating System Stress: High computational demand can overload system scheduling processes, causing delays in task execution, increased context switching overhead, and reduced responsiveness of system services.

[0072] Computational Cost Process: A process for determining the cost of code execution without requiring execution, comprising applying workload factors to a resource consumption representation of a scope of code, and subsequently applying a computing units process.

[0073] Code Cost Vision Engine: A computational analysis process that quantifies the estimated resource consumption required for executing a given set of code instructions without actual execution. Code Cost Vision determines the computational workload by analyzing factors such as CPU cycles, memory usage, disk I / O, and network operations. The process leverages deterministic execution principles to provide an assessment of execution costs in cloud, physical, or hybrid environments, without requiring execution.

[0074] Code Stress Vision Engine: A computational analysis process that evaluates the strain imposed by a given scope of code on a computing environment. The code stress vision engine can utilize the output of the code cost vision engine or an output derived from code execution.

[0075] Workload Factors: Parameters influencing execution cost, including execution frequency, concurrency levels, code line execution probability, input / configuration parameters, and scale points, defined manually or by an automatic gathering means. These factors determine the total computational load imposed on a system over time.

[0076] Scope of Code: A defined portion of code selected for analysis. The scope of code may be determined through manual selection by a user, automatic identification using Application

[0077] Performance Monitoring (APM) data, or a comprehensive scan of the entire codebase. Machine Language Instruction: A computing command generated from source code that is executed directly by hardware. Machine instructions are deterministic and define the exact computational steps taken by a processor.

[0078] Code Permutations: Functionally equivalent alternative versions of a given code segment, differing in structure but producing the same output.

[0079] Inefficient Code Pattern (ICP): A predefined structure or operation in a codebase that contributes to unnecessary computational waste.

[0080] Abstract Syntax Tree (AST): A hierarchical representation of a program’s structure used for code analysis and optimization. The AST captures logical relationships between functions, control structures, and data flow within the code.

[0081] CPU Operations: Computational processes handled by the central processing unit (CPU), including arithmetic logic unit (ALU) operations, register manipulation, context switching, and cache management.

[0082] Memory Operations: Actions involving random access memory (RAM), such as allocation, deallocation, cache usage, paging, and fragmentation overhead. Disk Operations: Data storage actions such as read / write requests, fragmentation overhead, disk swapping, locks, and wait times.

[0083] Network Operations: Actions involving data transmission over a network, including connection establishment, request-response cycles, protocol compression / decompression, parity checks, and packet validation.

[0084] Operating System Operations: System-level functions such as permission checks, access control, process scheduling, inter-process communication, and security enforcement.

[0085] Reference is now made to FIG. 1, which schematically illustrates code cost vision engine workflow 100, according to some embodiments of the invention.

[0086] According to some embodiments, code cost vision engine 106 is configured to estimate computational resource consumption for executing a given set of instructions and workload factors without requiring execution.

[0087] According to some embodiments, scope of code 101 is defined to establish the boundaries of the analyzed code segment. The scope may include an API, function, code snippet, service / micro-service, or software module, ensuring that computational estimations apply to a well-defined portion of the code, thereby facilitating a targeted assessment. According to some embodiments, workload parameters 102 defines the execution behavior under various conditions. These parameters may include execution frequency, concurrency levels, and total execution time. By incorporating workload variations, the system estimates total execution requirements over time and identifies inefficiencies that may only manifest under high-concurrency scenarios.

[0088] According to some embodiments, input / configuration parameters 103 define external factors influencing execution, including end-point parameters such as API request payloads.

[0089] According to some embodiments, code line probability 104 is assigned to each individual line of code, reflecting its likelihood of execution. This data is achievable by manual or auto-gathered means. Certain lines of code, such as those within conditional statements or loops, may not execute in every instance of function execution.

[0090] According to some embodiments, the system assigns weighted execution probabilities to each line of code. For example, a code line with 50% execute probability its resource consumption will be factored by 0.5.

[0091] According to some embodiments, scale points 105 are identified within the analyzed code, representing locations where external dependencies such as database queries, third-party API calls, or remote service interactions affect computational workload from that point onwards. By isolating these interactions, the system differentiates internal execution costs from those imposed by external services. According to some embodiments, workload parameters 102, input / configuration parameters 103, code line probability 104 and scale points 105 are collectively workload factors 110.

[0092] According to some embodiments, code cost vision engine 106 utilizes the workload factors 110 to generate a computational cost analysis, thereby quantifying execution costs across, inter alia, CPU usage, memory consumption, disk operations, and network interactions, enabling precise workload estimation without requiring program execution.

[0093] Reference is now made to FIG. 2, which schematically illustrates code cost vision process 200, according to some embodiments. As shown, code cost vision engine 106 is configured to analyze individual lines of code within a given scope and determine their estimated computational resource consumption. The process consists of multiple steps, including single code line extraction 201, machine language representation 202, applying workload factors 110, applying computing unit formula 204, single line code resource consumption 205, single line code operational cost 206, and repeating for each code line 207 across the entire scope of code, each of which is detailed below.

[0094] According to some embodiments, a single code line 201 is extracted from the scope of code. The extracted line represents an operation within the analyzed software, which may include, inter alia, arithmetic operations, control statements, function calls, memory access, and I / O operations. By analyzing the code at the line level, the system enables computation cost calculation, thereby determining the impact of each operation on resource consumption.

[0095] According to some embodiments, a machine language representation 202 is an example of a resource consumption representation, and is predefined for the extracted line of code, thereby providing a high-level programming language instruction into its corresponding low-level machine language commands, as processed by the CPU. These machine instructions are deterministic and define the precise computational steps executed by the hardware.

[0096] According to some embodiments, workload factors 110 may be applied to a resource consumption representation such as machine language representation 202. By applying workload factors 110 the code cost vision engine 106 quantifies the overall resource impact of a given code line across different execution scenarios.

[0097] According to some embodiments, computing unit formula 204 may be applied to determine estimated resource consumption for execution of single line of code 201. Computing unit formula 204 calculates CPU, memory, disk, network, and operating system interactions based on a resource consumption representation such as machine language representation 202 and workload factors 110. The computing unit formula considers computational metrics such as ALU operations, memory allocation overhead, disk I / O latency, and network transmission costs. By integrating these metrics, the system generates an estimation of the total resources required for execution. According to some embodiments, single line code resource consumption 205 calculates the total computational cost of executing a single line of code under the given workload conditions.

[0098] According to some embodiments, single line code operation cost 206 determines the operational cost by calculating the total resource consumption and applying cost estimation based on cloud provider pricing models. The calculation involves multiplying the computed resource usage (measured in computing units) by the average price per computing unit for the relevant resource types, including CPU, RAM, network, and storage usage.

[0099] According to some embodiments, the average price per computing unit is derived by analyzing publicly available pricing data from major cloud providers. The cost per unit is obtained by dividing the hourly pricing of cloud instances by the total number of computing operations those instances can perform in one hour at 100% utilization, based on their published hardware specifications.

[0100] According to some embodiments, an iterative process 207 is applied across all lines of code within the defined scope. The system repeats the analysis for each line, ensuring that the computational impact of every instruction is considered, thereby enabling global workload estimation across an entire function, service, or module, rather than isolated per-line assessments. According to some embodiments, code cost vision engine 106 integrates steps 201, 202, 203, 204, 205, 206 and 207 into a structured analytical process, allowing for deterministic computation cost estimation across entire codebases. By systematically analyzing each line of code, applying workload factors, and iterating across the full scope of code 101, the system provides a precise, execution-free methodology for quantifying computational resource requirements.

[0101] According to some embodiments, steps 203 and 204 constitute a computational cost process. When applied to the resource consumption representation machine language representation 202, the computational cost process generates output single line of code resource consumption 205.

[0102] Reference is now made to FIG. 3, which constitutes a schematic illustration of a code stress vision engine workflow 300, according to some embodiments. Stress vision engine 301 is configured to evaluate the estimated computational workload in relation to the available resources of a computing environment, thereby enabling computational stress determination.

[0103] According to some embodiments, code stress vision engine 301 utilizes the output of code cost vision engine 106 - resource consumption 107 - to determine the expected system load and assess how the estimated computational demand interacts with the available system resources. According to some embodiments, code stress vision engine 301 utilizes the output of an execution based code cost determination method.

[0104] According to some embodiments, environmental factors 302 define the computing infrastructure in which the workload is executed. These specifications include parameters such as CPU type, memory type, disk type, storage type, network bandwidth, and the functional behavior and resource overhead of the operating system.

[0105] According to some embodiments, stress vision engine 301 utilizes environmental factors 302 to calculate the stress imposed on a computing system by code execution over time.

[0106] According to some embodiments, code stress vision engine 301 utilizes resource consumption 107 and environmental factors 302 to determine the potential impact of executing the workload within the given computing environment, thereby providing environmental stress output 303.

[0107] According to some embodiments, the environmental stress output 303 provides an execution feasibility and demand classification.

[0108] Reference is now made to FIG. 4, which constitutes a schematic of code stress vision engine 301, according to some embodiments of the invention. As shown, code stress vision engine 301 calculates the estimated computational workload and determines the stress imposed on the computation environment. According to some embodiments, retrieving resource consumption 107 involves obtaining the precomputed resource consumption output from code cost vision engine 106. Said output defines, inter alia, the expected usage of CPU, memory, disk, and network resources for executing a given workload under specific conditions.

[0109] According to some embodiments, environmental factors 302 are summed in process 402 to determine total available resources for a given environment.

[0110] According to some embodiments, compute resource utilization ratio 403 involves comparing retrieved resource consumption 107 with retrieved available resources 402 to determine the percentage of system capacity that would be consumed by executing the workload, accounting for, inter alia, operating system (OS) overhead, thereby quantifying the computational effort required to complete the execution within the given system constraints.

[0111] According to some embodiments, procuring an evaluation of execution feasibility and resource demand classification 404 may involve classifying the workload’s execution demand into predefined effort levels based on the percentage of available resources required. The classification may include:

[0112] • Low Effort (<20%) - The workload is executed with minimal resource consumption.

[0113] • Medium Effort (20%-50%) - The workload utilizes a moderate portion of available resources. High Effort (51%— 75%) - The workload imposes significant resource demand but remains within operational limits.

[0114] • Extreme Effort (76%-100%) - The workload is near maximum system capacity, potentially affecting stability.

[0115] • Unstable Operation (>100%) - The workload exceeds available system capacity, leading to execution failure or severe performance degradation.

[0116] Reference is now made to FIG. 5, which schematically illustrates legacy code analysis workflow 500, according to some embodiments. As shown, code cost vision engine 106 is utilized to detect inefficiencies in pre-existing code and estimate computational cost.

[0117] According to some embodiments, code scope 101 determines the scope of the codebase to be analyzed. The scope may be manually defined by a user or automatically identified using Application Performance Monitoring (APM) data, which prioritizes frequently executed areas of the codebase. Alternatively, the system may scan the entire codebase to ensure comprehensive coverage.

[0118] According to some embodiments, code scan 501 retrieves the relevant code sections for analysis.

[0119] According to some embodiments, AST builder 502 generates an Abstract Syntax Tree (AST) representation of the extracted code. The AST captures the logical structure and execution flow of the program, providing a detailed map of potential execution pathways. According to some embodiments, function calling 503 utilizes a large language model

[0120] (LLM)-based function retrieval to extract the next relevant portion of the codebase iteratively.

[0121] According to some embodiments, function calling 503 interfaces with code repository 504, which serves as the primary storage for the complete codebase, thereby enabling the retrieval of the relevant code.

[0122] According to some embodiments, a Triage LLM 505 extracts the relevant ICPs to be applied to the AST. This model ensures that only relevant ICP undergo deeper evaluation - e.g., code that does not contain database queries is excluded from query-related inefficiency detection.

[0123] According to some embodiments, the system references a list of known inefficient code patterns 506. These patterns include operations that introduce computational waste, such as redundant computations, excessive memory allocations, unnecessary I / O operations, or inefficient looping structures.

[0124] According to some embodiments, each ICP is associated with an LLM detection prompt and a recommended optimization strategy. According to some embodiments, patterns LLM 507 scans the AST representation to detect the presence of any known ICPs. The model analyzes the structural and functional logic of the code in its full context and compares it against predefined inefficiency patterns.

[0125] According to some embodiments, the output of the patterns LLM 507 is a structured list of identified inefficiencies and optimization recommendations 508, including: precise locations of inefficiencies within the scope of code 101; classification of inefficiencies based on type (e.g., excessive memory allocation, inefficient loops, redundant operations); and recommended solutions for addressing each inefficiency.

[0126] According to some embodiments, the original and optimized versions of the code are processed in the code cost vision engine 106, which calculates resource consumption and computational cost before and after implementing the recommended optimizations. The analysis covers, inter alia, CPU usage, memory footprint, disk I / O operations, and network utilization, allowing for an objective comparison of computational efficiency before and after optimization.

[0127] According to some embodiments, workload factors 110 are incorporated into the analysis, thereby ensuring that the computational cost estimation accurately reflects real-world execution scenarios, thereby preventing overestimation or underestimation of inefficiencies. According to some embodiments, saving estimation 510 presents the final computational impact analysis sorted by impact, thereby providing a comparison of resource consumption before and after optimization.

[0128] According to some embodiments, savings estimate 510 includes computational saving for each ICP.

[0129] Reference is now made to FIG. 6, which schematically illustrates new code development analysis workflow with recommendation use case 600, according to some embodiments.

[0130] According to some embodiments, the process begins with code development / altering 601, wherein new code is procured by, for example, a code developer or an Al agent. During this process, the developer can initiate an on-demand code cost vision engine 106 calculation via a graphical user interface (GUI), allowing for an immediate assessments of the code’s computational cost in isolation.

[0131] According to some embodiments, workload factors 110 are included in the code cost vision engine 106 calculation. These factors include execution frequency, concurrency levels, and workload distribution over time.

[0132] According to some embodiments, pull request 602 submits the new or modified code to the code repository 603. According to some embodiments, code repository 603 contains an entire codebase and serves as a system for tracking and managing code changes.

[0133] According to some embodiments, webhook 604 is triggered upon detecting the pull request, and AST builder 605 constructs an AST representation of the submitted code in its full context.

[0134] According to some embodiments, function calling module 606 utilizes an LLM-based function calling to retrieve and analyze additional code sections.

[0135] According to some embodiments, triage LLM 607 extracts the relevant ICPs to be applied to the AST, thereby ensuring that only relevant portions of the code undergo deeper evaluation - e.g., a function without database queries does not need to be analyzed for query inefficiencies.

[0136] According to some embodiments, the system references a list of known ICPs 608 is used to detect code segments that contain unnecessary or redundant operations. These patterns include operations that introduce computational waste, such as redundant computations, excessive memory allocations, unnecessary I / O operations, or inefficient looping structures. Each identified ICP is associated with a corresponding LLM prompt and recommended optimization solution. According to some embodiments, patterns LLM 609 scans the AST representation to detect the presence of known ICPs by evaluating the structure and execution logic of the code, comparing it against predefined inefficiency patterns.

[0137] According to some embodiments, the output of patterns LLM 609 includes a list of identified ICPs, their precise location in the codebase, and recommended solutions to eliminate the wasteful operations

[0138] According to some embodiments, the original and optimized code versions are processed in code cost vision engine 106, which quantifies the resource consumption and operational cost before and after applying the recommended optimizations.

[0139] According to some embodiments, workload factors 110 are incorporated into the analysis. These factors include execution frequency, concurrency levels, and workload distribution over time.

[0140] According to some embodiments, saving estimation output 612 stores and presents the final analysis. The savings estimation output 612 includes the quantified computational savings for each identified ICP and a direct comparison of resource consumption before and after optimization and a cost-benefit assessment.

[0141] Reference is now made to FIG. 7, which schematically illustrates new code development analysis flow without recommendation use case 700, according to some embodiments. According to some embodiments, the process begins with code development 701, wherein, for example, a developer produces new code. The developer may initiate an on-demand code cost vision engine 106 calculation via a GUI to assess the computational resource requirements of their code before submission.

[0142] According to some embodiments, workload factors 110 are included in the code cost vision engine 106 calculation. These factors include execution frequency, concurrency levels, and workload distribution over time.

[0143] According to some embodiments, the developer submits the modified or newly developed code via pull request 702 to code repository 703. Code repository 703 contains the source code for the entire codebase. Webhook 704 is triggered upon detecting the pull request.

[0144] According to some embodiments, AST builder 705 constructs an AST representation of the submitted code. The AST captures the logical structure and execution flow, enabling further analysis of function dependencies, control structures, and execution paths in its full context.

[0145] According to some embodiments, function calling module 706 utilizes LLM-based function calling to retrieve and analyze additional sections of the code. According to some embodiments, triage LLM 707 extracts the relevant ICPs to be applied to the AST, thereby ensuring that only relevant ICP undergo deeper evaluation — e.g., code that does not contain database queries is excluded from query-related inefficiency detection.

[0146] According to some embodiments, the system references a list of known inefficient code patterns 708. These patterns include operations that introduce computational waste, such as redundant computations, excessive memory allocations, unnecessary I / O operations, or inefficient looping structures. Each ICP is associated with an LLM detection prompt and a recommended optimization strategy.

[0147] According to some embodiments, patterns LLM 709 scans the AST to detect the presence of any known ICPs. The model analyzes the structural and functional logic of the code in its full context and compares it against predefined inefficiency patterns.

[0148] According to some embodiments, no ICPs were detected 710. The original code is processed in the code cost vision engine 106 to calculate its resource consumption and cost estimation. This process quantifies the execution requirements for CPU, memory, disk, network, and other system resources.

[0149] According to some embodiments, workload factors 110 are incorporated into the analysis. Integrating workload factors ensures that the computational cost analysis reflects real- world operating conditions. According to some embodiments, estimated resource utilization 711 presents the computed resource consumption of the original code to the developer. This estimation provides insights into the computational cost of the code as it stands, without any modifications.

[0150] According to some embodiments, the developer code optimization 712 enables the developer to self-optimize their code based on the presented computational cost. The developer can refine the code and re-run code cost vision engine 106 to observe the estimated computational impact of their changes.

[0151] According to some embodiments, if the system identifies a modification that results in lower resource consumption for the same functionality, the optimized version is stored in optimized code storage module 713.

[0152] According to some embodiments, ICPs detected by way of developer code optimization 712 are added to the list of inefficient patterns 708, thereby improving the ability of patterns LLM 709 to detect inefficient patterns in subsequent analysis.

[0153] Reference is now made to FIG. 8, which schematically illustrates a code permutation assessment 800 for the identification of optimal code permutations, according to some embodiments. The system analyzes specific areas of a codebase, generates alternative functionally equivalent code permutations using an LLM, and evaluates them using code cost vision engine 106 to determine the most resource-efficient permutation. According to some embodiments, the process begins with code development 101, which can be novel, modified or legacy code.

[0154] According to some embodiments, code scan service 801 retrieves the relevant code segments for analysis. The scan scope may be defined manually by a developer or automatically identified using Application Performance Monitoring (APM) data, prioritizing frequently executed areas or scanning the entire scope of code 101 for inefficiencies.

[0155] According to some embodiments, AST Builder 802 constructs an AST representation of the retrieved code.

[0156] According to some embodiments, function calling module 803 utilizes LLM-based function retrieval to extract relevant sections of the scanned code iteratively.

[0157] According to some embodiments, code repository 804 serves as the primary storage for the complete codebase.

[0158] According to some embodiments, code permutation generator 805 generates alternative versions of the original code while maintaining identical functional behavior - that is, each permutation produces the same functional output for a given input. According to some embodiments, said code permutations are generated by LLM-based code permutation generator 806, which generates code permutations that may improve computational efficiency.

[0159] According to some embodiments, each generated code permutation is analysed by code cost vision engine 106 to evaluate its computational resource consumption. The analysis quantifies execution costs across, inter alia, CPU cycles, memory usage, disk I / O operations, and network activity, thereby ensuring that each permutation is evaluated in terms of overall system efficiency.

[0160] According to some embodiments, workload factors 110 are utilized by code cost vision engine 106. These factors include execution frequency, concurrency levels, and workload distribution over time, ensuring that the efficiency analysis reflects real-world operating conditions.

[0161] According to some embodiments, optimal permutation identification module 807 determines the most resource-efficient code permutation, which consumes the least computational resources while maintaining the same functional behavior as the original code.

[0162] Reference is now made to FIG. 9, which schematically illustrates an example system architecture, according to some embodiments of the invention. According to some embodiments, the system operates within a development environment 901, which may be deployed in a cloud-based infrastructure, a physical data center, or a hybrid environment.

[0163] According to some embodiments, application instances 902 serve as execution environments for software development. These instances provide computing resources for developers to write, debug, and test code before it undergoes formal validation and deployment. Some quality assurance (QA) tests may be performed directly on these application instances, while others occur in a dedicated QA / UAT (user acceptance testing) environment 903.

[0164] QA refers to the process of systematically testing software to identify defects and ensure compliance with technical requirements. UAT is conducted to validate whether the software meets user requirements and is ready for deployment by simulating real-world usage scenarios.

[0165] According to some embodiments, QA testing can be executed directly on application instances 902, for quick validation, debugging or load testing. Alternatively, QA / UAT tests can be conducted on dedicated QA servers 903.According to some embodiments, the system optionally includes an Application Performance Monitoring (APM) module 904, which tracks application performance and provides analytics on system behavior.

[0166] According to some embodiments, the code repository 905 stores and manages source code, thereby enabling developers to collaborate and track code changes and maintain version control. According to some embodiments, database (DB) instances 906 store application data across different environments. The DB instances may be implemented using relational database management systems (RDBMS or NoSQL solutions depending on application requirements.

[0167] According to some embodiments, the Codevisionary instance 907 is responsible for identifying computational waste, calculating cost and determining the stress outcomes within the system.

[0168] According to some embodiments, the Codevisionary instance 907 interacts indirectly with application instances 902 via the code repository 905. Code can be pushed to code repository 905 and subsequently retrieved by Codevisionary instance 907 for analysis.

[0169] According to some embodiments, a direct connection can be established between Codevisionary instance 907 and application instance 902, allowing for additional integration options.

[0170] According to some embodiments, Codevisionary’s can run locally on a dedicated instance, conferring improved data security compared with solutions deployed on third party systems.

[0171] According to some embodiments, cloud account management 908 maintains system configuration metadata, including information about allocated instances and storage types. Although the present invention has been described with reference to specific embodiments, this description is not meant to be construed in a limited sense. Various modifications of the disclosed embodiments, as well as alternative embodiments of the invention will become apparent to persons skilled in the art upon reference to the description of the invention. It is, therefore, contemplated that the appended claims will cover such modifications that fall within the scope of the invention.

Claims

CLAIMS1. A method for code based computational resource consumption management comprising the following steps:(i) obtaining a scope of code comprising at least one code snippet;(ii) associating resource consumption representation for each line of code within said scope of code;(iii) applying a computational cost process to determine the total number of computing operations required for execution of said scope of code; wherein the computational cost process is applied without executing computing operations.

2. The method of claim 1 , wherein the computational cost process includes the application of workload factors.

3. The method of claim 1, wherein the computational cost process output determines a stress level imposed on a computing environment based on the total number of computing operations required for execution.

4. The method of claim 3, wherein the computational cost process output is determined by code execution.

5. The method of claim 3, wherein the stress level is classified into predefined effort levels based on available system resources.

6. The method of claim 3, wherein execution feasibility can be determined based on the effort level.

7. The method of claim 1 , wherein the computational cost process output can be presented in any currency.

8. The method of claim 1, wherein the computational cost process detects and quantifies inefficient computing operations.

9. The method of claim 1 , wherein the computational cost process estimates the currencybased cost for code execution.

10. The method of claim 1, wherein the computational cost process accounts for central processing unit (CPU) operations.

11. The method of claim 1 , wherein the computational cost process accounts for random access memory (RAM) operations.

12. The method of claim 1, wherein the computational cost process accounts for disk operations.

13. The method of claim 1, wherein the computational cost process accounts for network operations.

14. The method of claim 1 , wherein the computational cost process identifies high resource consuming code within a the scope of code.

15. The method of claim 1 , wherein the computational cost process identifies wasteful code within a scope of code.

16. The method of claim 1 , wherein the computational cost process is operated upon pre- generated code permutations, thereby determining an optimal code permutation.

17. The method of claim 14, wherein an LLM generates said pre-generated code permutations.

18. The method of claim 14, wherein said pre-generated code permutations are generated manually.

19. The method of claim 1, wherein the output of the computational cost process is presented as a benchmark.

20. The method of claim 1 , wherein the computational cost process is applicable across all computing systems including cloud, physical and hybrid.

21. The method of claim 1, wherein the computational cost formula determines the percentage of available computational resources consumed by the scope of code.

22. The method of claim 1 , wherein the computational cost process incorporates execution frequency..

23. The method of claim 1 , wherein the computational cost process incorporates concurrent execution factors.

24. The method of claim 1 , wherein the computational cost process incorporates code line execution probabilities.

25. The method of claim 1, wherein the computational cost process accounts for external dependencies.

26. The method of claim 1 , wherein the computational cost process estimates the execution cost of a workload across all computing systems such as cloud, physical, and hybrid, etc.

27. A system for code based computational resource consumption management, comprising:(a) at least one CPU;(b) at least one memory storage means;(c) at least one I / O operator; and(d) optionally a network access means, wherein said components are configured to -(i) obtain a scope of code comprising at least one code snippet;(ii) associate resource consumption representation for each line of code within said scope of code;;(iii) apply a computational cost process to determine the total number of computing operations required for execution of said scope of code; wherein a computational cost process is applied without executing computing operations.

Images