flat assembler
Message board for the users of flat assembler.

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

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
itsnobody



Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD
itsnobody
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? Smile

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? Smile

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
Post 05 Feb 2008, 04:09
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
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.
Post 05 Feb 2008, 04:16
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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? Smile

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
Post 05 Feb 2008, 13:24
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.