vlsi commented on issue #4606: URL: https://github.com/apache/jmeter/issues/4606#issuecomment-1553289568
@pmouawad , sorry for pinging you here, however, I'm trying to figure out the use cases for the added feature. Unfortunately, I do not see end-to-end use case, so it is hard to understand when it would be useful. At the same time, the feature adds CPU-intensive code (it allocates memory on string concatenation to build variable names): https://github.com/apache/jmeter/issues/5875#issuecomment-1533369880 Even though we could try removing the allocations (e.g. cache the output of `org.apache.jmeter.util.JMeterUtils#formatJMeterExportedVariableName` instead of computing it on each iteration), it would be great to know the use-cases. Caching is not possible in `default` implementation of the interface, so it would require every implementation of `IteratingController` to implement its own cache, which is sad. Alternative implementations could be: * Add `iterator variable name` configuration property, so users could configure variable names they like. Then, if user does not use `iterator variable name`, they do not get the penalty. Of course, it would need to update the UI, however, then users would get more chances to discover the feature * Provide ability to expose "compute on demand" properties. Then the looping controllers could expose the variable just once, and it would request the current value from the controller when user requests it WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
