[GRASS-dev] [bug #2969] can wxPython GUI handle order of options for v.type and alike?

[Hamish]

Maciej Sieczka wrote:
> Having corrected the options I have tried again, on another machine.
> It shows that "v.type type=point,centroid,line,boundary" is about 35%
> faster than "v.type type=point,centroid; v.type type=line,boundary":


the extra time overhead is because it has to open and close the map(s)
an extra time.


[Cost]/benefit: the extra time cost should be considered both in light
of 1) how often a user wants to pack multiple conversions on the same
command line (rare <-?-> common), and 2) how big the time penalty is
(including how likely it is the module is to be used within a script
where the extra time is likely to be a significant proportion of the 
iteration).

My feeling WRT this time cost is that multiple conversions at once is
probably more rare than common, and the extra few seconds time penalty
when dealing with vector maps containing millions of features is tiny in
comparison to anything else you will do with a map of that size.
Considering it as just time a > time b is only one part of the story.
To be honest I am much more curious about the shadow of the
functionality change than the small time change.


In my mind the benefits of a simple + easy to use and understand
interface outweighs this small dt cost; or the cost of rewriting/
rethinking the parser logic (when only 2 of 393 modules are
problematic).


Hamish