Optimize load time about tweet-display-back

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

-edit-
Corrected the if ($count > 0) check in foreach loop, which improved loadtime a bit.
Problem is also the amount of data we need to download from Twitter. And that filtering occurs after downloading. Don't know if we can optimize that much.

[mbabker]

Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:
#2 (comment)
0

Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.

We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.

Op 27-6-2011 21:51, mbabker schreef:

Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:
#2 (comment)
0

[mbabker]

Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything we
can to optimize the code, we should be OK.

On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:

Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.

We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.

Op 27-6-2011 21:51, mbabker schreef:

Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:

#2 (comment)
22
0

Reply to this email directly or view it on GitHub:
#2 (comment)
8

Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)

Op 27-6-2011 22:00, mbabker schreef:

Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything we
can to optimize the code, we should be OK.

On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:

Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.

We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.

Op 27-6-2011 21:51, mbabker schreef:

Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:

#2 (comment)
22

0

Reply to this email directly or view it on GitHub:
#2 (comment)
8

[mbabker]

I have the option to turn caching on and off in the module params. I
could force it to always cache and just leave the option to set the cache
life, but I don't think that's too user friendly.

On 6/28/11 12:36 AM, "Twentronix"
[email protected]
wrote:

Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)

Op 27-6-2011 22:00, mbabker schreef:

Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything
we
can to optimize the code, we should be OK.

On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:

Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.

We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.

Op 27-6-2011 21:51, mbabker schreef:

Definitely the module once we start pulling too many tweets. Part of
it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as
a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:

#2 (comment)
48
22

0

Reply to this email directly or view it on GitHub:

#2 (comment)
99
8

Reply to this email directly or view it on GitHub:
#2 (comment)
8

Okay I see. But if it is neccesarily, that is maybe better then to
always turn it on. And maybe it is more user friendlier (one option less
that could be setup wrong). What would be negative side effects? Dunno
what's best to do. I'll leave that to you I think ;)

Met vriendelijke groet,
Jurian Even

Op 27-6-2011 22:09, mbabker schreef:

I have the option to turn caching on and off in the module params. I
could force it to always cache and just leave the option to set the cache
life, but I don't think that's too user friendly.

On 6/28/11 12:36 AM, "Twentronix"
[email protected]
wrote:

Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)

Op 27-6-2011 22:00, mbabker schreef:

Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything
we
can to optimize the code, we should be OK.

On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:

Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.

We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.

Op 27-6-2011 21:51, mbabker schreef:

Definitely the module once we start pulling too many tweets. Part of
it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as
a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:

#2 (comment)
48
22

0

Reply to this email directly or view it on GitHub:

#2 (comment)
99

8

Reply to this email directly or view it on GitHub:
#2 (comment)
8

[mbabker]

As many e-mails as I get about people getting the "you've reached the
limit" message, maybe it would be a better idea to force caching. I'll
solicit some feedback off the dev releases and figure something out before
2.0 is called a beta release.

On 6/28/11 1:00 AM, "Twentronix"
[email protected]
wrote:

Okay I see. But if it is neccesarily, that is maybe better then to
always turn it on. And maybe it is more user friendlier (one option less
that could be setup wrong). What would be negative side effects? Dunno
what's best to do. I'll leave that to you I think ;)

Met vriendelijke groet,
Jurian Even

Op 27-6-2011 22:09, mbabker schreef:

I have the option to turn caching on and off in the module params. I
could force it to always cache and just leave the option to set the
cache
life, but I don't think that's too user friendly.

On 6/28/11 12:36 AM, "Twentronix"
[email protected]
wrote:

Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)

Op 27-6-2011 22:00, mbabker schreef:

Caching is a must, otherwise you burn through the 150 pull requests
per
hour very quickly. At the end of the day, so long as we do everything
we
can to optimize the code, we should be OK.

On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:

Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.

We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we
could,
it would be nice to make it quicker yes.

Op 27-6-2011 21:51, mbabker schreef:

Definitely the module once we start pulling too many tweets. Part
of
it
is inevitably going to come down to the connection from the server
and
how
long it takes to query the data. I'm using 25 tweets on localhost
as
a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.

On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:

I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.

Reply to this email directly or view it on GitHub:

#2 (comment)
14
48
22

0

Reply to this email directly or view it on GitHub:

#2 (comment)
49
99

8

Reply to this email directly or view it on GitHub:

#2 (comment)
06
8

Reply to this email directly or view it on GitHub:
#2 (comment)
4

[mbabker]

In commit 938c7bc, I added an additional check to see if filtering was even active on mentions and replies, and if it wasn't, I just fed the data straight into processItem. I also moved the feeds check to before the filtering code. This should help slightly for those instances. I'm not quite sure there's much else that can be done at this point.