|
I once had to write a search-engine in ASP that did work with a XML database within one or two hours, OK the code worked, but it wasn't efficient at all, since then, I write programs as fast as possible, and I did write a new search-engine which hasn't even 100 lines of code (and is still fast and filters some words).
CString Dutch = "Double Dutch";
|
|
|
|
|
"Let's get down to the bottom line: C++ developers are old-school. They like knowing that their implementation is the fastest, that they aren't using memory when they don't need to be, and that their code is the smallest and tightest possible. The thing now is, huge amounts of CPU, disk and memory are available to most clients. e.g., it's not a big concern if an app uses 10MB, 20MB or 30MB when your user has 128MB+ of RAM."
Yeah you are right. And this situation is making harware companies earn billions. And if the trend continues the minimum requirement for doing "Hello World" program in Java would equire a Super Computer with Trillions of processors, Zillions MB of RAM  and still people would not be happy with the speed. 
"James R. Twine" would like to buy an IBM BlueGene see, http://www.research.ibm.com/bluegene/ to deploy an EJB. LOL.
|
|
|
|
|
Hey -- I am old-school too. But at a stage where the speed of most people's hardware gives them CPU cycles to burn, will a user even notice the difference between the languages in any practical sense? I wholeheartedly agree that there a subset of high-performance apps which need all the speed of C++. But most users aren't running those types of apps.
Why not put the extra memory & CPU to use helping the developer, in this case? In very direct terms, this benefits the user by making their products more reliable when the computer handles the truly irrelevant, burdensome details (bookkeeping tasks).
|
|
|
|
|
Maybe we should have a contest to see who can create the fastest executing solution to a common Windows programming problem... 
|
|
|
|
|
yes!
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
Us Rookies would get great benifit from seeing the pros duke it out on the same problem... seeing different approaches/techniques!
Scott!
Put the big rocks in the glass jar first!
|
|
|
|
|
Funny you should mention that...! I was working with Chris earlier for a way in which to have something similar to that. It was originally going to be a poll (what is the fastest way to add these two strings together, answer without trying the code out!), and offering a multiple choice to pick the best answer from the available choices.
Instead, I sent in this poll at the last minute to work on a better way to present it.
Maybe sometime...
Peace!
-=- James.
|
|
|
|
|
I would definitely be keen on holding a speed race!
So - start sending in your suggestions for problems that have many possible solutions, and can be coded up in a relatively small number of lines (I'm really not keen on wading through 50 x 1000 line solutions!)
cheers,
Chris Maunder
|
|
|
|
|
If it's done right there shouldn't be much code to wade through. It should simply be an input/processing/output kinda thing, with the results clearly verifyable.
The contest should be very carefully thought out so that it's not possible to short circuit the process. Virtually everytime I've been part of one of these a loophole was expoited by the winner, and it soured everyone.
I think this is a great idea.
So what do we pick? Sorts are an easy category, but have been done too often. Network Data transmission might be cool, optimized screen repainting, file patching using delta blocking, fastest spell checking engine for the CP forums (that would be close to home and important for everyone )
D
|
|
|
|
|
As opposed to a contest to create an executing solution to a common Windows programming problem the fastest?
I think that for most problems, this is the more important solution.
|
|
|
|
|
For those of you that selected "I try to optimize a few critical areas here and there", what exactly do you consider a "critical area"? I bet that there are QUITE a few different ideas on that one...
Not that my opinion/expertise seems to matter much here, but personally, I consider the entire application to be critical. Of course, you optimize the things that are "more critical" before the ones that are seemingly "less critical", but the whole application is what clients (or your boss) are paying for, not just parts of it.
Peace!
-=- James.
|
|
|
|
|
I selected that option, and I took "critical areas" as meaning those that are executed often enough that the extra effort will make a noticeable difference.
I didn't read "critical" as meaning "important to the proper execution of the program", as we are talking about speed optimization here, not reliability.
|
|
|
|
|
> [...] as we are talking about speed optimization here, not reliability
Ahhh! You have just hit upon the second part about what this poll is about: what does it mean to "work well"? Does it mean fast? Does it mean robust? Or does it mean both?
For example, to me, it means both.
Peace!
-=- James.
|
|
|
|
|
Well now, given that the question is about optimisation, I'd suggest that anyone who considers reliability to be a 'feature' on necessary in critical or core code, or in any way related to optimisation, then they should probably go back to being a plumber.
No offense, I'm sure you're applying different meanings to the terms than me, but in my eyes, all my software is written to be reliable, and any area that would benefit from a speed increase on a minimum spec machine is then optimised for speed without losing reliability.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
> No offense, I'm sure you're applying different meanings to the terms than me,
> but in my eyes, all my software is written to be reliable, and any area that
> would benefit from a speed increase on a minimum spec machine is then optimised
> for speed without losing reliability.
That was my point. From my previous post: "For example, to me, it means both."
"Works Well" means (to me) that code should be both at fast and as robust as possible. They may be mutually exclusive at their extremes, but often a good balance can be found.
-=- James.
|
|
|
|
|
It's critical if speeding up the code will make a noticable difference to the end user, and/or there is a noticable problem with the code as it stands.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I voted to optimize the entire program but.... I don't know about anyone elses code but my starting code base which all other programs my company writes run on top of starts in the neighborhood of 2500 classes. Unfortunatly that already adds some inefficiency into the works so the best that we can do is to write all of our code here and out and efficient as possible. As far as what a "Critical Area" is to me: A lot of the code I write runs machines which means it is very time dependent so a critical area is the code that send and recieves messages from the machine I am controling. If that code is not done as lean and mean as possible messages to and from it could be lost and the whole thing would just die. I think all to often this message boards think in just the terms of standard application development and don't give any thought to controller programs and RTOS.
Joseph Dempsey
jdempsey@cox.rr.com
Joseph.Dempsey@thermobio.com
"Software Engineering is a race between the programmers, trying to make bigger and better fool-proof software, and the universe trying to make bigger fools. So far the Universe in winning."
--anonymous
|
|
|
|
|
in my experience, you can't optimize the "whole application" because:
a) you aren't writing the whole thing - there are other people on the team, too.
b) the design is never finished - there is always some feature added late in the game that sits at 90 degrees to the architecture you've been using until then.
c) performance optimizations tend to narrow the focus of the code, removing flexibility.
for that reason, i rarely "optimize" anything but small high-traffic loops - anything more than that and the app starts to become brittle.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
> a) you aren't writing the whole thing - there are other people on the team, too.
Correct. That is the first problem in today's development teams: mismatched (and/or lacking) skillsets in some of the team members.
> the design is never finished - there is always some feature added late in the
> game that sits at 90 degrees to the architecture you've been using until then.
Yep. That is why we need to manage the customer's expectations, and make them aware of the simple fact that changes that need to occur later will result in greater cost.
> performance optimizations tend to narrow the focus of the code, removing
> flexibility. for that reason, i rarely "optimize" anything but small high-
> traffic loops - anything more than that and the app starts to become brittle
I think that would depend on how agressive the optimizations are done. If I am converting sections to hand-coded inline assembly, then I can se how problems can result.
Reality needs to be considered at all times. But as long as the archiecture remains flexible enough for its purpose, nothing is lost. Right?
-=- James.
|
|
|
|
|
My clients are not paying me to write the world's fastest software, and I suspect they would get quite upset if they found out I had wasted development effort and their money trying to optimize something that they can't notice.
Most problems I have dealt with have been I/O bound rather than compute bound, so optimizing code comes down to making the I/O happen faster.
I only focus on developing fast algorithms and using multiple threads some times to cache things. Reality is that the code will need to be modified soon to meet some new expectation from a client, so any hand optimized code will likely get unoptimized soon enough anyways.
Of course everybody profiles their code before optimizing...
|
|
|
|
|
Why java is so pathetically slow on 256 MB RAM and > 600 MHz P3 machines? Try debugging EJB with an IDE like VisualCafe and you'll instantly know what I am talking about.
|
|
|
|
|
> Why java is so pathetically slow on 256 MB RAM and > 600 MHz P3 machines?
Because dumbasses out there fall into the "Java trap", and believe stuff like this:
1: Java applications are just as fast as C/C++
2: Java applications are easier to write
Real #1: Java is an interpreted language. The VM that you use can do things like JIT compilation, or HotSpot technology, but those are only as good as the small closed group of people that designed/wrote them.
Real #2: Poor performing Java apps are easy to write. IMHO, and some others in my profession, it is like this: those that cannot write acceptable code in C/C++ usually can do so in Java and/or VB. Why? Because all of the "hard work" is taken care of (mem allocation, pointers, etc.), and there is less responsibility, and risk, placed on the developer. (True, there is *good* Java code that runs as well as *poor* C/C++ code. Read that again. IMHO, the time would be better spent writing the *good* C/C++ code.)
Also, anyone notice that the general solution to making Java applications perform better is simply to throw more metal (i.e. a bigger SUN box), rather that actually doing real work with the code to improve it?
> Try debugging EJB with an IDE like VisualCafe and you'll instantly know what
> I am talking about.
Most professionals already know the reality of Java. The others are in some form of (blissful) denial.
Peace!
-=- James
|
|
|
|
|
|
I work on J2EE enterprise systems professionally. I love Java, and I love J2EE, but I really feel your pain. It seems that speed has never been Java's strong point, but in the enterprise it's not as important as it is in client-side applications. From my experience, whether I'm writing for COM+ and MTS, or for EJB and J2EE application servers, it's always the database that slows things down. The performance I've seen from MTS and many J2EE application servers are similar, probably because of limitations on the speed of the database and how well indexing has been done.
I love Java because it seems that every area I use has a consistent feel to it. Whether I'm using JDBC, Java servlets, EJB, or just the Java API, everything has a very consistent feel. I thank God every day that I don't have to worry about COM automation data types anymore. It's a blessing to not deal with connection points anymore.
But, I think that once you develop for Windows, and especially using C++, you develop a taste for having very precise control over every aspect of a system. Sometimes I miss pointers. Yes, they can cause some nasty bugs sometimes, but I think when they're properly used, they do more good than harm. I actually enjoy doing my own memory management. It makes me feel good to know that the only things in memory are the things that absolutely need to be there. But mostly, here is my experience with Java and Java developers in general:
I hate to make sweeping generalizations, but some tend to be true. I have worked with a lot of software engineers in Microsoft camps, and a lot of software engineers in Java camps. It's been my experience that Java engineers tend to be less interested in the design of a system, and tend to develop rather haphazardly. I don't know why this is, but it's kind of like the difference between VB developers and C++ developers. I have had some amazing conversations with C++ developers, and they always seem to have a better idea of how/why things work than Java developers do. Don't get me wrong, there are some very skilled people working in the Java camp, but there seems to be a higher concentration of true skill in Microsoft camps. 
If you're still reading this very long post, thank you for your attention. If I can offer one piece of advice, it's this: if you know COM, ATL, COM+, or MTS then LEARN JAVA and J2EE NOW. Knowing Microsoft technologies makes me unique at my company, and makes me very valuable. Software engineers with skill and talent in both camps are incredibly hard to find, and as such can command insane salaries.  Stick with Microsoft, do Java when you have time, and have fun -- that's what it's really all about.
Now - for the original poster - Just do what my company did; upgrade to P-III 850's with 512MB RAM. It makes me sick that an IDE actually consumes enough resources to demand this kind of system, but hey - it makes a great Quake3 server machine at the end of the day.
|
|
|
|
|
WOW!!! what a precise and detailed answer.
Hey I have dont MS stuff a lot and these days I am doing Java etc. You mentioned fat salaries for the guys who know the both can you give some pointers (not C/C++ pointers of course!!!) where to get such salaries?
Another Anonymous!!!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
