Bug Infested Bloated Compilers

[Len]

I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.

No, that's not the reason. Most objects in Java & C# are referenced by pointers, you just don't explicitly see the pointer in the language. In other words, if you pass an object to a function, only a pointer is actually copied.

There are various other reasons that Java & C# can be slower than C & C++. In my experience, the biggest slowdowns come from (1) huge class libraries that cause slow startup times and memory hogging, and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it? 

[Karel]

... and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it?

Unfortunately, efficient programming costs more time & money than upgrading to a faster cpu & more memory.

[dannyf]

"500ish current part numbers,"

That's microchips biggest asset and it's biggest liability at the same time.

I suspect they make far more margins on those parts than on new parts. So a cash cow.

Because off that, they are very reluctant to venture into newer technology that may risk the cash cow. Killing themselves slowly over the long term.

[vodka]

I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.

No, that's not the reason. Most objects in Java & C# are referenced by pointers, you just don't explicitly see the pointer in the language. In other words, if you pass an object to a function, only a pointer is actually copied.

There are various other reasons that Java & C# can be slower than C & C++. In my experience, the biggest slowdowns come from (1) huge class libraries that cause slow startup times and memory hogging, and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it? 

i don't strange if every class have several subclasses inherited , plus properties that can be shared with other classes part to the main , adding that the method of the classes that too can be shared with others classes.

On resume , with the new  programming paradigm you have a  mess worse that gordian knot, and for this motive many programmer  that when they have to modify a java  application , the  form  more easiest is remaking since zero

[Howardlong]

... and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it?

Unfortunately, efficient programming costs more time & money than upgrading to a faster cpu & more memory.

Indeed, if you're developing for one person. If you're developing for 10,000, not so much.

But I do agree with your general views.

[eugenenine]

2.) Startup time of the IDE is 16 seconds (no SSD). I find this acceptable for a program that I usually start once a day.

Startup is under 10 seconds for me and I'm on a little old laptop that I paid $200 for so if its slower than that something is wrong with your OS.

[setq]

... and (2) no thought or effort put into performance by application programmers - you've got 16 GB and 3 GHz, so why worry about it?

Unfortunately, efficient programming costs more time & money than upgrading to a faster cpu & more memory.

Yes and no. That approach works fine if you ship your code to an end user as you distribute the load away from what costs you money. If you own your infrastructure, rent it from Amazon/Google etc or have a monolithic black box somewhere in your architecture, this never adds up to a viable approach. There's a wall and it gets way more expensive than programmer time at a point in the future because you need to spend the cash right up front to climb over it. Programmers increase linearly. Infrastructure capacity/scale, not so much. Unfortunately balancing this and feature creep is one of my many hats.

[Karel]

Indeed, if you're developing for one person. If you're developing for 10,000, not so much.

I don't agree. A programmer (or his boss) that develops a program for 10,000 people, doesn't care that they (the 10,000 people)
have to pay for a faster cpu & more ram.

[elgonzo]

There's a wall and it gets way more expensive than programmer time at a point in the future because you need to spend the cash right up front to climb over it. Programmers increase linearly. Infrastructure capacity/scale, not so much. Unfortunately balancing this and feature creep is one of my many hats.

Except, your wall analogy is not generally true.
While it is true that you have to pay up front for new and faster hardware, you immediately get the what you paid for: faster performance. Whereas with software development, the costs accumulate over time until the desired optimization is ready for release, but you also have to wait for that long until you can benefit from it. As the saying goes: time IS money...

[mikeselectricstuff]

Indeed, if you're developing for one person. If you're developing for 10,000, not so much.

I don't agree. A programmer (or his boss) that develops a program for 10,000 people, doesn't care that they (the 10,000 people)
have to pay for a faster cpu & more ram.

Nothing to do with caring or not - simple business.
If you're shipping 10K units, you can spend up to slightly less than $10K on work that saves $1 per unit

[setq]

There's a wall and it gets way more expensive than programmer time at a point in the future because you need to spend the cash right up front to climb over it. Programmers increase linearly. Infrastructure capacity/scale, not so much. Unfortunately balancing this and feature creep is one of my many hats.

Except, your wall analogy is not generally true.
While it is true that you have to pay up front for new and faster hardware, you immediately get the what you paid for: faster performance. Whereas with software development, the costs accumulate over time until the desired optimization is ready for release, but you also have to wait for that long until you can benefit from it. As the saying goes: time IS money...

I disagree. Hardware only goes so far. When you have to pay for a cluster of two active-active 48 core E7 Xeons with 1024Gb of RAM, associated enterprise SSDs and then the SQL Server license for it because you hit that wall you will understand what I mean by hardware cost.

My point is performance management is a continual process that you need to factor into every feature or architectural change.

[Sal Ammoniac]

I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.

I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.

Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.

Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.

[mikeselectricstuff]

For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.

Depends on what sort of stuff you're doing - ICD3 is definitely way faster for larger parts, but PK3 works just fine for smaller ones, and is more tolerant to abuse - IME ICD3 can get itself into wierd states that sometimes need exiting and restarting  MPLAB to recover. I usually use PK3 on small 8-bit parts - there was definitely a good reason for this that I found years ago, but I've long since forgotten exactly what it was & don't know if it's even still an issue.
Even if you have an ICD3, you certainly should also have a PK3, partly as a backup, but also for the programmer-to-go function which is very handy if you have more than a few boards to program.
 

[setq]

I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.

I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.

Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.

Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.

I understand the justification but I genuinely wish people didn't use this approach. We have a massive problem where someone writes some code on their Cray sized workstation and doesn't understand that it has to execute in under 50ms when it hits production on something with less wumph, more load, higher concurrency and less per thread heap. The tool bloat contributes to this problem because the supporting software runs like shit on even the best of kit so you have to do the yearly upgrade treadmill. And thus disparity between reality and the development team increases.

Typical comparison:

Dev: high end i7 8 cores, 32Gb of RAM, m2 SSD.

Prod: 1/16th of an E5 Xeon core which is virtualized, 77Mb of RAM, SAS 10K disk.

[JPortici]

I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.

I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.

Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.

Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.

sometimes you just have to.
a lot of accounting and government software will not work with something newer than win2k or XP (i think it has something to do with the hardware license) or with newer version of software.
some manager in politics decided that PA here is forced to use open source crap like openoffice 1.5 and no updates because of some custom plugins that were never updated by the software house. this is true nightmare, my mother is adamantine on not wanting them to upgrade her pc to a new one because on her old she is still allowed to use office 2000 and get at least some work done
my point being, you aren't always allowed to upgrade

[JPortici]

Not so simple for Public Administration (PA). There is a policy they have to keep. Those in change of determining the policy seem not to be able to look at the data on how many times higher the downtime and the cost for manteinance is, compared to a windows pc
 It's already a miracle they didn't force them to use older ubuntu, and boy if they tried

[mikeselectricstuff]

I'm still amazed that some people still don't get the simple fact that time is money (in a commercial environment). I see a lot of people stuck with using old, slow PCs, poor tools, etc., all because their management won't pay to upgrade their working environment.

I still see people using PCs with only 1 GB of RAM, single 15" monitors, hard drives instead of an SSD, etc. It's amazing what some people will put up with and how cheap management can be. It's this kind of short-sighted, penny-wise-pound-foolish thinking that leads to projects way over schedule and full of bugs.

Good tools, relatively speaking, don't cost much and they generally return more value than they cost in the long run. For example, no one should be using a PICKit3 for commercial development--ICD3 should be the minimum. Heck, if I was at a company where they expected me to use a PK3, I'd buy an ICD3 with my own money just to keep my sanity.

Maybe corporate bean counters should be forced to use Excel 2.0 on a PC from 1992 for a few months so they can experience for themselves what it's like to work with out of date, inferior tools.

I understand the justification but I genuinely wish people didn't use this approach. We have a massive problem where someone writes some code on their Cray sized workstation and doesn't understand that it has to execute in under 50ms when it hits production on something with less wumph, more load, higher concurrency and less per thread heap. The tool bloat contributes to this problem because the supporting software runs like shit on even the best of kit so you have to do the yearly upgrade treadmill. And thus disparity between reality and the development team increases.

Typical comparison:

Dev: high end i7 8 cores, 32Gb of RAM, m2 SSD.

Prod: 1/16th of an E5 Xeon core which is virtualized, 77Mb of RAM, SAS 10K disk.

There's a major difference between using a powerful PC to write PC applications, and, what we are mostly talking about here,  using it for a cross-compiling tool, where the power of the PC has no bearing on the performance of the final application, other than reducing development time.

A similar situation to the "powerful PC to develop PC apps" scenario can often be seen with websites, where they clearly have a fast low-latency connection for their own development and testing, but the actual experience on a normal connection sucks.

[JPortici]

Libre and OO work like a charm now. Past verion didn't.
1.5 was total shit but they can't update to new versions because of custom plugins that won't be upgraded
Same with java 6
Same with most software they use

[VK3DRB]

If you are writing code for one person or 10,000 people, efficient code should always be an aim, based upon pride in doing a good job. Actually more important than that is well written, well structured, well commented and well documented code. Like laying out a PCB should be considered artwork, so should writing code.

[Karel]

If you are writing code for one person or 10,000 people, efficient code should always be an aim, ...

Keep on dreaming. In the real world where time is money and deadlines are set, (almost) nobody cares.

[setq]

Unfortunately some of us are paid to supervise a team of people who don't care and that's where it gets all 

[VK3DRB]

If you are writing code for one person or 10,000 people, efficient code should always be an aim, ...

Keep on dreaming. In the real world where time is money and deadlines are set, (almost) nobody cares.

I didn't say THE aim. I said AN aim. From what I have seen, most shoddy work is usually fuelled by laziness. Time and money are important, but I know of an idiot who runs a small business with a "whatever is cheapest" attitude. He has lost hundreds of thousands of dollars - possibly a half a million dollars or more - through false economy and not listening to his employees. Intelligent and successful people realise the importance of investment in good compilers, good tools and good people.