What is faster? calling lstrcat or using only mov and add?

Index > Windows > What is faster? calling lstrcat or using only mov and add?

Goto page Previous 1, 2

Author

Thread

itsnobody

Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD

itsnobody 05 Feb 2008, 04:09

f0dder wrote:

itsnobody wrote:

f0dder wrote:

itsnobody wrote:
So then why use Assembly? Why not use Java or Visual Basic if speed doesn't matter?

Indeed, why not?

If you're writing a database frontend, you might as well write it in VB and save yourself a lot of trouble. Assembly wouldn't gain you anything, except perhaps personal satisfaction and wanking rights.

Well that's true for some simple apps or apps that don't require any real speed

Which is most applications that most regular users will be using.

True, but if they unnecessarily waste memory it wastes time

Quote:

itsnobody wrote:
But I think that's the problem with programmers, they don't care about speed anymore

A lot of people don't have it as their prime design criteria. Personally I value correctness/robustness and ease-of-use over speed, for most stuff.

I prefer both

Quote:

itsnobody wrote:
Well lots of applications right now running are constantly calling some type of strlen function, like for instance a web browser or text editor or many other applications...

Do they, now? Where's your data to back up this claim?

I think one of those API Monitoring programs will show it, though I'm not sure

Quote:

itsnobody wrote:
all that wasted time adds up from milliseconds to seconds to lag...it would be noticable if all applications used the fastest strlen and string functions...

Oh really?

In the real world, we profile applications to detect bottlenecks, so we know where to put our optimization efforts.

Really? Is that so?

I think it matters a lot and will add up, but there's no way to show this

Quote:

itsnobody wrote:
if all applications used the fastest super-optimized functions it would be a lot faster

Not really.

Fisrt of all, you should stay away from most of the libc str* functions, as they are inherently unsafe. Next, one size doesn't fit all, and if you try to cover all cases, you end up with franken-functions with lots of (slow) branches.

[/QUOTE]
Nah I think it would

Thats the problem with Windows programs being slow and inefficient, no emphasis on speed anymore

05 Feb 2008, 04:09

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 05 Feb 2008, 04:16

itsnobody wrote:

Thats the problem with Windows programs being slow and inefficient, no emphasis on speed anymore

Well, if you don't test on slow processors, you'll never notice the difference, and hence you can't fix it.

P.S. Anybody claiming to not care about speed is forgetting the -O2 and more used by most compilers when compiling most anything. (Faster but still correct.) People care much more for speed than small size.

05 Feb 2008, 04:16

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 05 Feb 2008, 13:24

itsnobody wrote:

True, but if they unnecessarily waste memory it wastes time

Where did memory enter the picture? I thought we were discussing *str* functions? Anyway, wasting memory doesn't necessarily mean wasting time.

itsnobody wrote:

f0dder wrote:

A lot of people don't have it as their prime design criteria. Personally I value correctness/robustness and ease-of-use over speed, for most stuff.

I prefer both

Which is fine if you're a hobbyist programmer that has all the time in the world, but if we're talking about real-world software, you often have to make compromises.

itsnobody wrote:

f0dder wrote:

itsnobody wrote:
Well lots of applications right now running are constantly calling some type of strlen function, like for instance a web browser or text editor or many other applications...

Do they, now? Where's your data to back up this claim?

I think one of those API Monitoring programs will show it, though I'm notsure

So, you admit you don't really know what you're talking about?

Sure thing, with Process Explorer from sysinternals, you can see what code a thread is currently running, but you can't use that for accurate profiling - considering how little time *str* functions take to execute, I don't think you'd ever actually see that name in the thread list.

itsnobody wrote:

f0dder wrote:
In the real world, we profile applications to detect bottlenecks, so we know where to put our optimization efforts.

Really? Is that so?

I think it matters a lot and will add up, but there's no way to show this

As I already said, profiling will show you where your hot spots are.

itsnobody wrote:

itsnobody wrote:
if all applications used the fastest super-optimized functions it would be a lot faster

f0dder wrote:
Not really.

Fisrt of all, you should stay away from most of the libc str* functions, as they are inherently unsafe. Next, one size doesn't fit all, and if you try to cover all cases, you end up with franken-functions with lots of (slow) branches.

Nah I think it would

Thats the problem with Windows programs being slow and inefficient, no emphasis on speed anymore

And I think you're talking out of your ass Smile

rugxulo wrote:

Well, if you don't test on slow processors, you'll never notice the difference, and hence you can't fix it.

I keep a 350MHz PII with 64 megs of ram in the closet Smile

05 Feb 2008, 13:24

Goto page Previous 1, 2

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum