I'd really rather not use functions

I'd really rather not use functions unless necessary. Each use would be two needless branches. I could use macros, but then I wouldn't be able to optimize at a very fine grain.

Azu wrote:

I'd really rather not use functions

Not a big fan of structured programming?

Azu wrote:

I'd really rather not use functions unless necessary. Each use would be two needless branches. I could use macros, but then I wouldn't be able to optimize at a very fine grain.

Just have three different files, one file have the length prefix code, another the null terminate, etc. then selectively include one of them and test with it.

I did. Twice.

buzzkill wrote:

Azu wrote:

I'd really rather not use functions

Not a big fan of structured programming?

Structs are fine. They just make it easier to read/write the code and don't effect performance.

Azu wrote:

I did. Twice.

Not really, you gave some vague ideas but no hard figures to work with. Proper optimisation requires precise information else you risk getting the wrong outcome.

Azu wrote:

buzzkill wrote:

Azu wrote:

I'd really rather not use functions

Not a big fan of structured programming?

Structs are fine. They just make it easier to read/write the code and don't effect performance.

I meant, normally you would divide your program into functions, each one containing a piece of the total functionality. This helps to keep your program logically structured, and promotes code reuse. If you really think that using functions is a waste because of a call/ret, I wonder what your programs look like...

String comparison (checking if two strings are equal, and at what byte they differ if not) scanning (seeing if a byte (or substring) exists in a string, and at what byte), and copying (setting the bytes in one string to the bytes in another), with strings of varying sizes, and a big load.

Azu wrote:

String comparison (checking if two strings are equal, and at what byte they differ if not) scanning (seeing if a byte (or substring) exists in a string, and at what byte), and copying (setting the bytes in one string to the bytes in another), with strings of varying sizes, and a big load.

Okay, so what are the ratios of each function? How long are the strings on average? Shortest? Longest? How many strings in total? Length of the search sub-string? Can you store meta data in the DB that has time saving precomputed info? How much of the system time is likely to be spent in string routines compared to other non-string routines? What CPU? What memory size/speed? etc.

I think it would be easier just to code up two or three versions and test.

Those are unknown except for on my own computer, under some artificial test. Which is why I am trying to figure out which is faster in general.

unless you change the underlying algorithms or some other fundamental change.

But you still need to define how much time is spent processing strings? Is it 10%, 90%, what? I can't imagine an app that needs such a large amount of time just to process strings, but nevertheless, you did say that you want to optimise so naturally that means just for your situation.

String scanning, appending, searching algos etc. are also reliant on the type of strings you use. The length, the composition, the expected match hit position etc. You still need to define you usage model! You don't have to define it to me, but to yourself. And then you can start to make better decisions about what way to move forward with algo selections.

What I mean is, these things will be varying drastically. I don't know what % are going to be long and what % are going to be short, or how much % of the CPU is going to be used. Under this condition should I base the program on null termination, or prepended length?

For example if all your strings are expected to be < 4 bytes then null termination may work out great. But what if all the string are > 1 MB then maybe length prefix is better. What if you need to have a null in the string, well then your decision is easy, length prefix. Hmm, what about an app that uses lots of printf type function calls, well then null termination might be just the thing.

Azu wrote:

What I mean is, these things will be varying drastically. I don't know what % are going to be long and what % are going to be short, or how much % of the CPU is going to be used. Under this condition should I base the program on null termination, or prepended length?

Well if you don't know, then how can anyone else know? Nobody is omnipotent! (well not me anyway )

I just want to know which is faster in general for string operations; null or length?

var            db var.len
          db 'foo',30+var2
          dw var3
             dd 0,1
var.len               equ $-var    

var.len = $ - var ; ("=" instead of "equ")