|
On the desk right, next to the one I'm sitting right now, sits my first computer and its 4k RAM has been working for 34 years now. My current PC has only 4 million times as much
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
...but that's only because the machine came with it - I would have specified 2GB if I was building it myself instead of buying off the shelf.
Why? So that my machine was the same or lower spec than my customers. If it works well on mine, it will work excellently on theirs...
If your Dev Box is too high a spec, then you assume that the performance you get is what the client will get, and that just ain't always true. Better to find out at the beginning that there is a performance problem (when it is easy to fix) than on delivery!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Well said
|
|
|
|
|
In the ideal world a dev would have at least 2 machines. One proper one for development and a machine for testing, same spec as that of users. That would be more productive.
|
|
|
|
|
|
I agree with that reasoning for test environments, but not for main dev.
- build time is usually wasted developer time.
- debug builds can be significantly slower than release builds
- most devs today rely on a giganormous tool chain
My main project (re-)builds in about 20 minutes on my office system, 50 minutes on a build machine that has roughly custoemr specs. With a heavily parallelized build, it's hard to use the machine for something else in that time.
|
|
|
|
|
I agree with you - but I don't work on massive projects.
But I'd expect a project of that size to be a team build, and to have a dedicated test section, which should use equipment slightly lower spec'ed than the end user's.
The problem is the "mine is bigger than yours" attitude of developers means that even for little projects we want Uber-PC at all times, and since the debugger is on the dev machine...
It's a whole lot cheaper to fix performance problems at an early stage then after you hand a near complete project to the customer for initial comments
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
peterchen wrote: builds in about 20 minutes
peterchen wrote: 50 minutes on a build machine
Perhaps its finally time to get rid of that old 486
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
It's a decent two-core Athlon (IIRC), monitoring the repository for changes. It's ok for now - and we are supposed to move to the new servers once they arrive.
Anyway, what I wanted to say: Turnaround times don't matter that much for a build server than for the local dev machines.
|
|
|
|
|
I disagree nothing disturbs me more than a slow development environment that can't keep up with me. I use Virtual Machines to tech down and test my apps.
|
|
|
|
|
I use virtual machines for testing, and need the extra RAM to spin those up in a decent amount of time. The virtual machines only have 2GB RAM to reveal performance issues, but the dev machine has 8GB.
|
|
|
|
|
OriginalGriff wrote: So that my machine was the same or lower spec than my customers
Since I work on the company website and we just got some new servers in a load balanced environment, I guess that means I should have 2 machines, each with 16GB of RAM. I'll put in the request now that you have given me a good reason.
|
|
|
|
|
Actually I prefer to develop on a high end machine and run a virtual machine inside it to do the first performance tests. That way you can have a more dynamic approach to this issue and have a machine that can withstand time for a few years before dying on you
V.
|
|
|
|
|
Quote: It's cheap and gives the biggest bang for your buck when developing. Why skimp?
This is one insane utter stupid follow-up for the question
No developer or admin or manager should/will grant RAM or any other hardware excessively just because they are Cheap
It all depends on the kind of service/product that the developer is developing.
Developing on too much alien or high end environment (than the target system) may lead to nightmares while testing and deploying
|
|
|
|
|
Lakamraju Raghuram wrote: Developing on too much alien or high end environment (than the target system) may lead to nightmares while testing and deploying
Although I agree with this statement completely, the development software in general requires more RAM, not the app you are writing.
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011) "No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011)
"It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)
"But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)
|
|
|
|
|
10 years ago, I might have agreed with you. But with the development of virtual machines, it really doesn't matter what platform I develop on, so long as I can test it and debug it on the target platform. Virtual machines make it easier to create real world situations to test on.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
In most cases the only difference between disappointment and depression is your level of commitment. -- Marc Maron
I am not a chatbot
|
|
|
|
|
I should really think about upgrading to 16GB at home though.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
In most cases the only difference between disappointment and depression is your level of commitment. -- Marc Maron
I am not a chatbot
|
|
|
|
|
Same although I don't have a requirement to upgrade to 16GB, I don't even come close to using 8GB
|
|
|
|
|
My main development machine is at work with 4GB. But on my personal PC at home I have 16GB!
|
|
|
|