in my opinion in this case you should take care for algo size too . ..
cuz the search for '.'is real fast you dont have a lot of bytes to check . so the speed is not the importent thing size is importent as well

buliaNaza: i think you have a mistake in the algo

when you do "sub ecx, 4D4D4D4Dh" it wont work all the time ..
you will get carry if ecx<4D ,4D ,4D ,4D not just if the bytes = 4D

anyway here is my try
it will work only in cases like bazik needs
(the string always! extension and path("\"))

Posted on 2002-01-06 12:51:23 by eko

I'm sorry but this is an idea only NOT working proc...

U can't evaluate my idea because you don't know what I have under the labels Search_14: and Search_15: ...

In your proc u use "standard" things with xor value, other Value and then standard sub value, 1 to find out the zero...
If I have a free time this week I will finish my idea with
a little bit "non standard" code...
Posted on 2002-01-06 16:14:42 by buliaNaza
I must admit I do not see a single problem with Bazik's code, its compact, clear and more than fast enough to do very large numbers of paths.

It would be problematic to even work out how to benchmark the variations and if you could work it out, the differences would be trivial.

Optimisation is related to relevant performance, the person who saves 10 cycles loading a system dialog box will never see the difference where a person who writes a blitting routine or a search algo or a sorting algo has something useful to work on where the difference is useful and the result produces a better program.

Anything else is naval introspection for no purpose.

Not withstanding such weighty considerations, have a look at the MASM32 library module called "NameFromPath" for a different approach to the problem of extraction file names from complete paths.


Posted on 2002-01-06 18:33:30 by hutch--