On Tue, 2005-10-11 at 11:09 -0700, ModelCitizen wrote: > Free Lunch Wrote: > > The performance problems are mainly due to the way the slimserver > > software is written. Throwing hardware at the problem will not solve > > those design issues.
I generally find that throwing hardware at most problems solves performance. or at least makes it tolerable. I ran SlimServer on a P3-500 box for over a year. It could have been faster, but it worked fine. When the CPU fan died and fried the CPU, I got a AMD 2200+ or so, and it is more than fast enough for me. > So it's worse than I thought then? It's not solely a problem with Perl > code performing badly on Windows machines (which in my experience is > always been the case), it's just that SlimServer is fundamentally > flawed and needs some part of the core rewriting. I remember when SD > first mentioned the proposed SlimServer "upgrade" from 5.** to 6.** > Robin Bowes was adamant that this should include making the application > multi-threaded. Unfortunately his suggestion was not taken up. In > retrospect it looks like it should have been. I'm not sure I want to jump into a discussion with such heated terminology. The discussion of whether the database back end or multi-threading should be first priority got a lot of discussion. Both are big jobs. With limited resources, one has to make decisions. The potential for growth in functionality using the database is huge. The re-implementation for multi-threading will only help folks who don't get the performance they want from their hardware. You are, of course, welcome to join [EMAIL PROTECTED] and help with the effort. I don't see much point in complaining about water than is over the dam and way downstream by now. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
