From: Ethan A Merritt <sfeam@us...>  20121023 20:31:28

On Saturday, October 20, 2012 10:22:12 pm sfeam (Ethan Merritt) wrote: > On Saturday, 20 October 2012, sfeam (Ethan Merritt) wrote: > > On Saturday, 20 October 2012, Dima Kogan wrote: > > > The optimization you're describing is more powerful. > > > Do you think there will be a noticeable difference > > > between the two approaches with realworld data? > > > > It is very hard to predict what data someone might > > someday want to plot. Here is a simple script that > > generates highly redundant commands by drawing a > > series of vectors touching headtotail. > > Suppression of the intervening M commands would reduce > > the size of the output stream by 50%. > > And here's another pathological case. > This one is actually pretty common, or at least it > arises from a plot style I use often enough in real life. > It's a scatter plot with variable color points, > except that many (all in this example) of the points > are the same color. Again suppression of the redundant > commands (g000000 in this example) gives a reduction in > size approaching 50%. I went ahead and modified x11.trm to filter out these two common cases, using exactly the same logic already used by the svg, canvas, and pdf terminals. The emf and post terminals do something similar but the details are different. Filtering yields a 9% reduction in the number of bytes sent from gnuplot to gnuplot_x11 during execution of all.dem. Running uniq on the filtered output reports that < 0.1% of the remaining output lines are exact duplicates. That sets a rough estimate on the expected benefit from more sophisticated filtering. On the other hand, applying Dima's earlier patch on top of this, which switches to binary output for vectors, gains an additional 3%. I expect that using binary for moves as well as vectors would gain a bit more. So that may still be worth pursuing. I suppose there remain other terminals that could benefit from filtering to reduce the size of the output. lua? aqua? Ethan 