[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226848#comment-13226848 ] Emmanuel Bourg commented on CSV-43: --- What is the efficiency issue you are concerned with? Is it the creation of 5 instances to define a format? CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226862#comment-13226862 ] Sebb commented on CSV-43: - Yes, every fluent method creates a new instance. That seems very wasteful. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226880#comment-13226880 ] Oliver Heger commented on CSV-43: - Wouldn't this be a good candidate for the builder pattern (Bloch, Effective Java, item 2)? The nested Builder class implements the fluent interface and eventually creates an immutable instance of CSVFormat. Maybe, as an extension, the Builder could be seeded with an existing CSVFormat instance if a new instance is to be derived from an existing one. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226888#comment-13226888 ] Sebb commented on CSV-43: - Yes, a builder would also work, and would allow the class to be truly immutable. However it would mean bigger changes to the API. A simpler fix would be to add a flag to reject further changes. Not immutable, but thread-safe since code uses volatile. Either fix would be fine by me. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226898#comment-13226898 ] Emmanuel Bourg commented on CSV-43: --- It's less efficient than a direct instantiation, but that doesn't make the API inefficient. The critical part is the parsing, concerns about the efficiency should be focused on this part of the code. I don't want to make the API more complex with an additional CSVFormatBuilder class or extra steps to define a format. This is quite similar to the design of the Guava API for example, such as the Joiner/Splitter classes. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226591#comment-13226591 ] Sebb commented on CSV-43: - OK, but so long as the predefined formats are frozen, it would still be possible to code the fluent API more efficiently. The simplest way would be to add a flag that stops further updates. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
