eo benchmarks

[levBagryansky]

It can be useful to measure eo performance in future. I think it can be looked like this:
By analogy with +tests we can add +benchs to eo files.
Such files should be translated to java benchmakrs:

public final class EOadd_testTest extends PhDefault {  
...
public static class MyBench {      
  @Benchmark  
  @OutputTimeUnit(TimeUnit.NANOSECONDS)   
  @BenchmarkMode(Mode.AverageTime)   
  @Fork(value = 1, warmups = 1 )   
  @Warmup(iterations  = 2)  
  public static void works(final Blackhole blackhole) throws java.lang.Exception {  
    blackhole.consume(new Dataized(new EOrust_find_returns_int_0Test()).take());  
  }  
}

}

and run by mvn clean install -Pbench.
In addition we can add similar command to eoc like eoc bench <EO object> . This will generate java class with benchmark calls to dataization of EO class and run it.

[github-actions]

@levBagryansky thanks for the report, here is a feedback:

Problems

• The submitted bug report seems to be more in line with a feature request or suggestion, lacking essential components that define a comprehensive bug report.
• Absence of a clear, succinct description of the issue or bug within the software is evident. No explanation of an error, fault, or system failure is provided.
• The bug report's title lacks descriptiveness and fails to communicate the problem effectively.

Suggestions

• Define the Nature of the Report: Since the current report looks more like a feature request, it should be clarified whether this is a bug report or a feature request. If it's a bug report, then it should include a specific problem or error in the software. If it's a feature request, it should be submitted in the appropriate channel for feature suggestions.
• Provide a Clear, Concise Title: The title of the bug report should precisely articulate the problem. A good bug title should give a brief summary of the issue, which can help developers quickly understand the nature of the problem. For example, if it's a bug, a better title could be "EO Benchmarks: Issue with EO files translation to Java benchmarks".
• Describe the Problem Clearly: A comprehensive bug report should include a clear and concise description of the problem. It should detail what the issue is, where it occurs, and its impact on the software. If it's a feature request, it should describe the desired feature, why it is needed, and how it could improve the software.
• Expected vs Actual Result: For a bug report, include the expected result and what the actual result was. This gives a clear comparison of what should happen and what is actually happening.
• Reproduction Steps: Any good bug report should include steps to reproduce the issue. This helps the development team to understand and investigate the problem more efficiently.
• System Information: Include relevant details about the environment in which the problem was encountered. This could include the software version, operating system, and any other relevant system information.
• Screenshots or Logs: If applicable, include screenshots, logs, or any other relevant data that can help illustrate the problem or the desired feature. This can provide more context and help the development team understand the issue better.
• Proposed Solution: If you have a proposed solution or workaround, include it in the report. This can be especially helpful in dealing with bugs and can guide the development team in the right direction.
• Remember to keep the report factual and avoid including opinions or unnecessary information. Also, ensure that the report is well-structured and easy to read. This can greatly assist the development team in identifying and resolving the issue more efficiently.

Please fix the bug report in order it to get resolved faster.
Analyzed with gpt-4