[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Did anyone read the GNOME story where somebody found out GNOME was reading a 200k XML file at startup just to set the system volume? It's these kinds of silly things -- and lots of them -- which really cause the slowdown and poor performance in juggernauts such as GNOME and //shudder// KDE. On Wed, 23 Mar 2005 18:16:39 +0000, Neil Williams <linux@xxxxxxxxxxxxxx> wrote:
On Wednesday 23 March 2005 1:17 am, Martin White wrote:With reference to the last point, software hasn't really needed to be small or quick in the last, I dunno how many years!There are projects where small, efficient codebases are maintained. Certain projects also pride themselves on the purity of the code in order to maintain the widest possible platform support. I believe in keeping things simple but sometimes you just have to get involved in the spaghetti code. Sometimes projects co-opt a programmer to do a particular task (especially awkward things like modularisation or abstraction) but the task is never finished - it can take a while to undo the changes and get back to a straightforward design. Personally, I believe tools like doxygen take a lot of credit for keeping code understandable - it's easy to document code in comments as you go and the process *can* be used by the programmer to make the code itself cleaner and easier to follow. Documenting your code as you go can have a large impact on the final codebase. Just reading your own documentation can highlight duplication, redundancy, poor design and lack of modularity. My own PHP code could probably be difficult to follow - I tend to over-use conditionals and loops, resulting in overly-complex nests. It took me ages to get used to using modules in Perl - I kept re-inventing a lot of the basic stuff.Developers in certain fields (I don't think it would be fair by any means to say globally) have been spoilt.Certain fields, yes, but the projects I've worked on have strong lead developers who insist on wide platform support and clean code.The CPUs were getting ever faster and the amounts of memory people were stuffing into their PCs were getting ever vaster.Embedded systems are the best challenge - try getting your application to fit within what's left of the original 20Mb after the OS loads!But without keeping all that up to date, from where I'm sat it would seem that technology has hit a temporary brick wall on speed and size. I'm assuming this is why all of a sudden manufacturers are putting as much effort (maybe more?) into going quieter, cooler and smaller.Bloat is responsible for a lot of exploits and bugs - that may be part of it. -- Neil Williams ============= http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.neil.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-- ~ Ben Goodger ~ Please remember to FLOSS daily. ~ www.getfirefox.com -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. FAQ: www.dcglug.org.uk/linux_adm/list-faq.html