Remove layerstates multi drawings.

Exactly what I was thinking - although the performance of the 'foreach' shines through with the compiled test (updated above).

Interesting. Similar to the test with repeat/while for stepping through selection sets. The vl-remove-if being faster still boggles my mind, but it must be the slowness of reverse.

Interesting. Similar to the test with repeat/while for stepping through selection sets. The vl-remove-if being faster still boggles my mind, but it must be the slowness of reverse.

More curious is why that double vl-remove-if-not should be faster than my modifications to make it into a single vl-remove-if-not (layerstate-list2)...

More curious is why that double vl-remove-if-not should be faster than my modifications to make it into a single vl-remove-if-not (layerstate-list2)...

That's what I was referring to. Forgot to type the 'double' part, but yeah, that is beyond strange.

I'd also have thought a single vl-remove-if-not with an anded check inside would be quicker than 2 separately. Though I guess it depends on the scenario, how many states to look through, how long their names are, what the wc is and how it matched. But going a bit deeper I think the main issue is the checking being done with an = to the car for a 3 and then swapping some register to do a different type of check using text. There may be a slight time delay when changing to-and-fro between these 2 forms of checking (i.e. putting something else into a different state). Thus it could be that this time delay is removed if you first do all the checking for number equality and then do the wild-card match on the resulting list. Not to mention, performing the combined vl-remove-if-not effectively does a cdr twice for each found item in the list.

BTW, isn't alan's suggestion much the same as my VERY first code? I simply didn't reverse back then. True the (if (and could be greatly optimized as alan suggests, though in the scheme of things it doesn't matter that much. And anyway, we're talking about fractions of seconds here.

But the real issue is that the test doesn't work as this particular code would be used in the real-life world. The test performed the same calls 8000+ and 16000+ times to arrive at the final figures. I can't see where a call to this function would be necessary more than 1 to a few times. Thus a much better test would have been to first create a DWG with 1000's of layer states, that way the bias would not be so much about the start of the defun (i.e. the obtaining a list of DXF codes for the layer states dictionary) than it would for actually stepping through the list and extracting only the matching versions.

Of course, where you to draw such line? At 1-to-10 as Lee's done, or at 1-1000's as I'm suggesting?

BTW, isn't alan's suggestion much the same as my VERY first code? I simply didn't reverse back then. True the (if (and could be greatly optimized as alan suggests, though in the scheme of things it doesn't matter that much. And anyway, we're talking about fractions of seconds here.

Must have overlooked your first submission. Sorry about that.

Ditto - apologies Irneb, I really only focussed on your rewritten code.

No worries.

I switch from one to the other from time to time. In the past I've seen a minor increase in performance through the use of 'function' since this perhaps removes some legwork for the interpreter, but I believe the difference is very small indeed.

 

_$ (setq l '(1 2 3 4 5))
_$ (repeat 8 (setq l (append l l)))
_$ (setq m (reverse l))

_$ (Benchmark '((mapcar '+ l m) (mapcar (function +) l m)))

Benchmarking ................Elapsed milliseconds / relative speed for 8192 iteration(s):

   (MAPCAR (FUNCTION +) L M).....1981 / 1 <fastest>
   (MAPCAR (QUOTE +) L M)........1982 / 1 <slowest>

$ (Benchmark '((mapcar '(lambda (e1 e2) (- (+ (/ (* e1 e2) pi) e1) e2)) l m) (mapcar (function (lambda (e1 e2) (- (+ (/ (* e1 e2) pi) e1) e2))) l m)))
Benchmarking .............Elapsed milliseconds / relative speed for 1024 iteration(s):

   (MAPCAR (QUOTE (LAMBDA (E1 E2) (- (+...).....1578 / 1.00 <fastest>
   (MAPCAR (FUNCTION (LAMBDA (E1 E2) (-...).....1578 / 1.00 <slowest>

So I can't see any real use for the function "optimization". Maybe it had some benefit on one of the very old interpreters in the 90's and now the lambda itself gets optimized in the same way.