On Sat, 26 Jan 2002, Perrin Harkins wrote:
> > It all depends on what kind of application do you have. If you code is
> > CPU-bound these seemingly insignificant optimizations can have a very
> > significant influence on the overall service performance.
>
> Do such beasts really exist? I mean,
On Sat, 26 Jan 2002, Stas Bekman wrote:
[...]
> > It's much better to build your system, profile it, and fix the bottlenecks.
> > The most effective changes are almost never simple coding changes like the
> > one you showed, but rather large things like using qmail-inject instead of
> > SMTP, cac
One memory & speed saving is using global VARS, I know it is not
recomended practice, but if from the begining of the project u set a
convention what are the names of global vars it is ok..F.e. I'm using in
all DB pages at the begining :
our $dbh = dbConnect() or dbiError();
See I know (i'm sure
Hi all,
Stas has a point. Perl makes it very easy to do silly things.
This is what I was doing last week:
if( m/\b$Needle\b/ ) {...}
Eight hours. (Silly:)
if( index($Haystack,$Needle) && m/\b$Needle\b/ ) {...}
Twelve minutes.
73,
Ged.
Perrin Harkins wrote:
> Back to your idea: you're obviously interested in the low-level
> optimization stuff, so of course you should go ahead with it. I don't
> think it needs to be a separate project, but improvements to the
> performance section of the guide are always a good idea.
It has
On Saturday 26 January 2002 03:40 pm, Sam Tregar wrote:
> Think search engines. Once you've figured out how to get your search
> database to fit in memory (or devised a cachin strategy to get the
> important parts there) you're essentially looking at a CPU-bound problem.
> These days the best sol
On Sat, 26 Jan 2002, Perrin Harkins wrote:
> > It all depends on what kind of application do you have. If you code is
> > CPU-bound these seemingly insignificant optimizations can have a very
> > significant influence on the overall service performance.
>
> Do such beasts really exist? I mean, I
On Sat, 26 Jan 2002, Perrin Harkins wrote:
>> It all depends on what kind of application do you have. If you code
>> is CPU-bound these seemingly insignificant optimizations can have a
>> very significant influence on the overall service performance.
>
> Do such beasts really exist? I mean, I gu
> It all depends on what kind of application do you have. If you code is
> CPU-bound these seemingly insignificant optimizations can have a very
> significant influence on the overall service performance.
Do such beasts really exist? I mean, I guess they must, but I've never
seen a mod_perl appl
Perrin Harkins wrote:
>>The point is that I want to develop a coding style which tries hard to
>>do early premature optimizations.
>>
>
> We've talked about this kind of thing before. My opinion is still the same
> as it was: low-level speed optimization before you have a working system is
> a
Stas Bekman <[EMAIL PROTECTED]> writes:
> I even have a name for the project: Speedy Code Habits :)
>
> The point is that I want to develop a coding style which tries hard to
> do early premature optimizations.
I disagree with the POV you seem to be taking wrt "write-time"
optimizations. I
On Fri, 2002-01-25 at 13:15, Matt Sergeant wrote:
> With qmail, SMTP generally uses inetd, which is slow, or daemontools,
> which is faster, but still slow, and more importantly, it anyway goes:
>
> perl -> SMTP -> inetd -> qmail-smtpd -> qmail-inject.
>
> So with going direct to qmail-inject
On Fri, 25 Jan 2002 21:15:54 + (GMT)
Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> With qmail, SMTP generally uses inetd, which is slow, or daemontools,
> which is faster, but still slow, and more importantly, it anyway goes:
>
> perl -> SMTP -> inetd -> qmail-smtpd -> qmail-inject.
>
> S
On 25 Jan 2002, David Wheeler wrote:
> On Fri, 2002-01-25 at 09:08, Perrin Harkins wrote:
>
>
>
> > It's much better to build your system, profile it, and fix the bottlenecks.
> > The most effective changes are almost never simple coding changes like the
> > one you showed, but rather large thin
On Fri, 2002-01-25 at 09:08, Perrin Harkins wrote:
> It's much better to build your system, profile it, and fix the bottlenecks.
> The most effective changes are almost never simple coding changes like the
> one you showed, but rather large things like using qmail-inject instead of
> SMTP, cach
> The point is that I want to develop a coding style which tries hard to
> do early premature optimizations.
We've talked about this kind of thing before. My opinion is still the same
as it was: low-level speed optimization before you have a working system is
a waste of your time.
It's much bet
> This project's idea is to give stright numbers for some definitely bad
> coding practices (e.g. map() in the void context), and things which vary
> a lot depending on the context, but are interesting to think about (e.g.
> the last example of caching the result of ref() or a method call)
I t
Issac Goldstand wrote:
> Ah yes, but don't forget that to get this speed, you are sacrificing
> memory. You now have another locally scoped variable for perl to keep
> track of, which increases memory usage and general overhead (allocation
> and garbage collection). Now, those, too, are insi
Ah yes, but don't forget that to get this speed, you are sacrificing
memory. You now have another locally scoped variable for perl to keep
track of, which increases memory usage and general overhead (allocation
and garbage collection). Now, those, too, are insignificant with one
use, but the
Rob Nagler wrote:
> Perrin Harkins writes:
> Here's a fun example of a design flaw. It is a performance test sent
> to another list. The author happened to work for one of our
> competitors. :-)
>
>
> That may well be the problem. Building giant strings using .= can be
> incredibly slow
> When you dig into it, most sites have a lot of data that can be out of sync
> for some period.
Agreed. We run an accounting application which just happens to be
delivered via the web. This definitely colors (distorts?) my view.
> heavy SQL. Some people would say to denormalize the database a
> Perrin Harkins writes:
> > To fix this, we moved to not generating anything until it was requested.
We
> > would fetch the data the first time it was asked for, and then cache it
for
> > future requests. (I think this corresponds to your option 2.) Of
course
> > then you have to decide on a ca
Perrin Harkins writes:
> To fix this, we moved to not generating anything until it was requested. We
> would fetch the data the first time it was asked for, and then cache it for
> future requests. (I think this corresponds to your option 2.) Of course
> then you have to decide on a cache consi
> I'm interested to know what the opinions are of those on this list with
> regards to caching objects during database write operations. I've
encountered
> different views and I'm not really sure what the best approach is.
I described some of my views on this in the article on the eToys design,
w
> 1) The old cache entry is overwritten with the new.
> 2) The old cache entry is expired, thus forcing a database hit (and
> subsequent cache load) on the next request.
3) Cache only stuff which doesn't expire (except on server restarts).
We don't cache any mutable data, and there are no sessi
I'm interested to know what the opinions are of those on this list with
regards to caching objects during database write operations. I've encountered
different views and I'm not really sure what the best approach is.
Take a typical caching scenario: Data/objects are locally stored upon loading
26 matches
Mail list logo
