Nabble - Mozilla - Performance

Re: HTML 5 Canvas: Linux Performance Issues

2009-10-08T16:08:19Z

On Oct 8, 11:03 pm, Boris Zbarsky <bzbar...@...> wrote:

> On 10/8/09 3:40 PM, Will Daniels wrote:
>
> > That would be cool, though to be honest I haven't really looked at it
> > properly myself yet, and no doubt you have bigger fish to fry ;) I
> > would be embarrassed if it turned out to be just my lousy javascript
> > knowledge. Though on second thoughts, it does work fine in all other
> > cases...so I don't know...maybe if someone could just confirm for me
> > that it *is* lagged with the standard Mozilla builds for Linux, in
> > case I did something wacky with the install?
>
> I can certainly confirm that, in my Linux VM. No lag on the small
> mandelbrot, but quite noticeable lag on the big one.

That _really_ is odd, since the zoom box itself is actually the same
size in both! I wonder if there is some delay then on the getImageData
relative to the size of the source context perhaps? I have to do some
more tests, though I don't think that can happen until the weekend
now...no reason to hurry anyway I guess.

> I believe 64-bit jit will happen in Firefox whatever-is-after-3.6.

Nice :) If there's anything I can do to help there, please let me
know. I'm not at all familiar with the Firefox architecture or code,
but I'm a capable programmer, a fair mathematician and a very fast
learner :P

Perhaps there are some relatively isolated areas of the JIT code that
I could get a sufficient handle on quickly to help with? Otherwise, I
don't mind just doing a bit of testing or something - I'd like to do
my bit to make sure Firefox's Linux performance is as good as it can
be.

Thanks again for your assistance here,
Will
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: HTML 5 Canvas: Linux Performance Issues

2009-10-08T13:03:10Z

On 10/8/09 3:40 PM, Will Daniels wrote:
> That would be cool, though to be honest I haven't really looked at it
> properly myself yet, and no doubt you have bigger fish to fry ;) I
> would be embarrassed if it turned out to be just my lousy javascript
> knowledge. Though on second thoughts, it does work fine in all other
> cases...so I don't know...maybe if someone could just confirm for me
> that it *is* lagged with the standard Mozilla builds for Linux, in
> case I did something wacky with the install?

I can certainly confirm that, in my Linux VM. No lag on the small
mandelbrot, but quite noticeable lag on the big one. No visible lag on
either one on the host OS (Mac).

I hadn't gotten past confirming yet, but _something_ is going on there.
My guess is painting, though that doesn't explain why you don't see it
in the Ubuntu builds....

I believe 64-bit jit will happen in Firefox whatever-is-after-3.6.

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: HTML 5 Canvas: Linux Performance Issues

2009-10-08T12:40:28Z

Hi Boris, thanks for your reply!

On Oct 8, 3:17 am, Boris Zbarsky <bzbar...@...> wrote:

> Just as a note: none of the Mozilla.org builds are done with icc. The
> Windows builds (which use PGO) are done with MSVC.

LOL, OK, not sure where I gathered that misconception from then,
though I guess it's not substantively important anyway, especially in
view of:

> Just to check... were the Ubuntu builds 64-bit, by any chance? If so
> (and this is my most likely hypothesis at the moment), you're probably
> seeing the lack of a 64-bit jit in Firefox 3.5.3's JS engine. The
> mozilla.org builds are 32-bit.

Aha, yes that makes a _lot_ more sense than putting it down to PGO! I
am indeed using the 64-bit Ubuntu binaries (though it came as some
surprise when I checked - obviously I'm not booting from the root
partition that I thought I was :D). In any case, I was not aware that
there's no/limited JS JIT on 64-bit, so I guess that explains it well
enough, given the degree of floating-point arithmetic involved.

> > PS: If anybody can suggest also why the rendering of my fractal "zoom
> > box" (on the mousemove event) is noticeably lagged using the Mozilla
> > Linux build, but not the Ubuntu build (or any other build of any other
> > browser on any other platform that I tried)
>
> _That_ is really odd. I'll look into that.
>
> -Boris

That would be cool, though to be honest I haven't really looked at it
properly myself yet, and no doubt you have bigger fish to fry ;) I
would be embarrassed if it turned out to be just my lousy javascript
knowledge. Though on second thoughts, it does work fine in all other
cases...so I don't know...maybe if someone could just confirm for me
that it *is* lagged with the standard Mozilla builds for Linux, in
case I did something wacky with the install?

Cheers!
Will
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: HTML 5 Canvas: Linux Performance Issues

2009-10-07T17:17:58Z

On 10/7/09 6:54 PM, Will Daniels wrote:
> After testing a number of different browsers on different platforms, I
> concluded that: Opera is consistently slow, Chromium is consistently
> "swift", and Intel/PGO builds of Firefox are consistently fastest.

Just as a note: none of the Mozilla.org builds are done with icc. The
Windows builds (which use PGO) are done with MSVC. Last I checked, icc
porting work was sporadically happening, but not done.

> I'd really like to help improve performance of GCC builds of Firefox,
> but I don't (yet) know anything about whether the PGO capabilities of
> GCC are used in building the Ubuntu Firefox package

Almost certainly not; GCC with PGO enabled ends up with internal errors
in its profiling information bookkeeping if you try to use it on
Firefox. As in, the PGO is just too buggy to use so far.

The Linux builds mozilla.org ships are not using GCC's PGO either.

> or indeed whether it is PGO primarily that is making the difference here (i.e. perhaps
> the Intel compiler is just that much better at optimising this
> particular arithmetic case).

Just to check... were the Ubuntu builds 64-bit, by any chance? If so
(and this is my most likely hypothesis at the moment), you're probably
seeing the lack of a 64-bit jit in Firefox 3.5.3's JS engine. The
mozilla.org builds are 32-bit.

> One thing in particular I'd like to ask here, is whether you keep any
> 3.5.3 Linux binaries that are compiled with the Intel compiler without
> the PGO phase, for comparison?

As I said above, I don't think it's even possible to build Firefox with
icc at the moment. I could be wrong about that, though!

> PS: If anybody can suggest also why the rendering of my fractal "zoom
> box" (on the mousemove event) is noticeably lagged using the Mozilla
> Linux build, but not the Ubuntu build (or any other build of any other
> browser on any other platform that I tried)

_That_ is really odd. I'll look into that.

-Boris

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

HTML 5 Canvas: Linux Performance Issues

2009-10-07T15:54:36Z

Hi everyone!

I started playing with HTML 5 canvas the other day, rendering
fractals, and I noticed an enormous (2000%) disparity in performance
between Ubuntu Linux and Windows builds of Firefox 3.5.3 (see
http://willdaniels.co.uk/blog/14-math-stuff/28-playing-with-fractals-in-html5).

After testing a number of different browsers on different platforms, I
concluded that: Opera is consistently slow, Chromium is consistently
"swift", and Intel/PGO builds of Firefox are consistently fastest.

I'd really like to help improve performance of GCC builds of Firefox,
but I don't (yet) know anything about whether the PGO capabilities of
GCC are used in building the Ubuntu Firefox package, or indeed whether
it is PGO primarily that is making the difference here (i.e. perhaps
the Intel compiler is just that much better at optimising this
particular arithmetic case).

So I thought this might be the best place to ask for pointers to help
me figure all this out, and that perhaps you might otherwise be
interested in this example as a clear demonstration of the immense
performance impact the compiler can have on occasion.

One thing in particular I'd like to ask here, is whether you keep any
3.5.3 Linux binaries that are compiled with the Intel compiler without
the PGO phase, for comparison?

Any information on this subject gratefully received! :)

Cheers,
Will

PS: If anybody can suggest also why the rendering of my fractal "zoom
box" (on the mousemove event) is noticeably lagged using the Mozilla
Linux build, but not the Ubuntu build (or any other build of any other
browser on any other platform that I tried) I would appreciate that
also :P It's very odd because it is only using getImageData and
putImageData the same as the much improved rendering of the main
fractal image, yet I can't think what else might influence the
responsiveness of the mousemove event :S
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-09-02T12:46:15Z

>> which pages or test cases show this? can you point at one or put one
>> together?
> Next time I come across one I'll post it here.
>
http://twitter.com/rbmax

http://twitter.com/** for that matter.
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Ogg Theora Video Tag

2009-08-30T20:50:02Z

I've been noticing performance problems with Ogg Theora video tag. It
uses up all of my CPU (it's like an 7 year old Pentium 4) and the video
is choppy (probably from the CPU being overpowered). I've read up on
this in bugzilla where there are existing bugs on this. Improving this
doesn't seem like it would be a small task, but It's disappointing to
not be able to use the new video tag yet. I'm currently using nightly
builds of Firefox 3.7a1pre for windows.

Are there plans to focus more on Video tag performance for 3.6 or 3.7?
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T16:20:29Z

gperry wrote:
> here, if further prove were needed that extensions make little
> difference to the bloat, here is firefox after 5 minutes of randamly
> opening and closing sites, no extensions, no themes.
> http://smg.photobucket.com/albums/v91/c0ldfury/?action=view¤t=Capture-1.jpg

Interesting. That doesn't match my experience at all, but certainly
looks like a real issue. I assume this is Firefox 3.5.x? Do you think
you can send me the list of sites loaded during that session? Is there
a bug filed?

> Do those plugins account for the 100s of megs of aculated bloat that
> FF carries with it?

Some Flash versions leak like a sieves, so "maybe", depending on what
you're doing, which exact plug-in versions you're using, which Firefox
version you're using, etc...

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T12:17:49Z

On 30/08/2009 19:47, gperry wrote:

> On 30/08/2009 18:08, Martijn wrote:
>
>> Do you have any extensions installed? Do you use a different theme
>> than the default one?
>> What cpu speed do you have?
>>
>> Regards,
>> Martijn
>>
>>> _______________________________________________
>>> dev-performance mailing list
>>> dev-performance@...
>>> https://lists.mozilla.org/listinfo/dev-performance
>>>
>>
>>
>>
> here, if further prove were needed that extensions make little
> difference to the bloat, here is firefox after 5 minutes of randamly
> opening and closing sites, no extensions, no themes.
> http://smg.photobucket.com/albums/v91/c0ldfury/?action=view¤t=Capture-1.jpg
>

minutes later; http://img.photobucket.com/albums/v91/c0ldfury/Capture-2.jpg
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:58:37Z

On 30/08/2009 19:42, Mike Beltzner wrote:

> On 30-Aug-09, at 2:25 PM, gperry wrote:
>
>> I am not looking for support, I don't need it. I'm just surprised to
>> see so little performance related development despite reading, on
>> nearly every forum, I visit a continually stream of
>
> I've already pointed you to other forums where discussion is taking
> place, and encourage you to review and contribute in any of the
> discussions there. We discuss performance weekly at our development
> meeting. If you're interested, here are some links:
>
> bugs:
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw:%22[ts%22
>
> project details:
> https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements
>
> meeting notes:
> https://wiki.mozilla.org/Platform/2009-08-25#Startup_Performance
> https://wiki.mozilla.org/Platform/2009-08-18#Startup_Performance
>

I am familiar with bugzilla, and that it also shows a lack of interest
in performance related issues.
The other links seems to be startup time related, which is actually one
of the least important performance aspects.

> The specific issues you are seeing are not commonplace, and all due
> respect, you're misreading the memory values between applications and
> not comparing apples to apples (for instance, the firefox.exe process
> also reports memory consumed by plugins, which iexplore.exe and
> chrome.exe do not).
Do those plugins account for the 100s of megs of aculated bloat that FF
carries with it?
>
> If I've misread your tone,
You have indeed.

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:50:15Z

On 30/08/2009 19:47, gperry wrote:
> On 30/08/2009 18:08, Martijn wrote:

> here, if further prove were needed that extensions make little
> difference to the bloat, here is firefox after 5 minutes of randamly
> opening and closing sites, no extensions, no themes.
> http://smg.photobucket.com/albums/v91/c0ldfury/?action=view¤t=Capture-1.jpg
>

apologies; http://img.photobucket.com/albums/v91/c0ldfury/Capture-1.jpg
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:47:06Z

On 30/08/2009 18:08, Martijn wrote:

> Do you have any extensions installed? Do you use a different theme
> than the default one?
> What cpu speed do you have?
>
> Regards,
> Martijn
>
>> _______________________________________________
>> dev-performance mailing list
>> dev-performance@...
>> https://lists.mozilla.org/listinfo/dev-performance
>>
>
>
>

here, if further prove were needed that extensions make little
difference to the bloat, here is firefox after 5 minutes of randamly
opening and closing sites, no extensions, no themes.
http://smg.photobucket.com/albums/v91/c0ldfury/?action=view¤t=Capture-1.jpg
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:42:51Z

On 30-Aug-09, at 2:25 PM, gperry wrote:

> I am not looking for support, I don't need it. I'm just surprised to
> see so little performance related development despite reading, on
> nearly every forum, I visit a continually stream of

I've already pointed you to other forums where discussion is taking
place, and encourage you to review and contribute in any of the
discussions there. We discuss performance weekly at our development
meeting. If you're interested, here are some links:

bugs:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw:%22[ts%22

project details:
https://wiki.mozilla.org/Firefox/Projects/Startup_Time_Improvements

meeting notes:
https://wiki.mozilla.org/Platform/2009-08-25#Startup_Performance
https://wiki.mozilla.org/Platform/2009-08-18#Startup_Performance

The specific issues you are seeing are not commonplace, and all due
respect, you're misreading the memory values between applications and
not comparing apples to apples (for instance, the firefox.exe process
also reports memory consumed by plugins, which iexplore.exe and
chrome.exe do not).

If I've misread your tone, and you actually do wish to get involved
and assist, I apologize and look forward to your contributions.
However, your existing tone has been hostile and sarcastic to date,
and I'm not really interested in getting into arguments about whether
or not the Mozilla community cares about performance or its users.
You're free to believe as you wish, and contribute if it's within your
interest. If you merely wish to complain, consider it registered and
choose to believe what you will about our desire to fix the issue.

cheers,
mike
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:25:54Z

On 30/08/2009 18:14, Mike Beltzner wrote:

> On 30-Aug-09, at 1:08 PM, Martijn wrote:
>
>> Do you have any extensions installed? Do you use a different theme
>> than the default one?
>> What cpu speed do you have?
>
> If these are the problems the user should go to http://support.mozilla.com
>
> My impression is that while well-intentioned, we're just feeding a troll
> here. Let's not.
>
> cheers,
> mike

I am not looking for support, I don't need it. I'm just surprised to see
so little performance related development despite reading, on nearly
every forum, I visit a continually stream of complaints about the
increasing drop of performance in the mozilla apps. The fact that you
think this is a support issue, imo, again reflects this apparent
disconnect between end-users and the devs here.
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:21:35Z

On 30/08/2009 18:18, chris hofmann wrote:

> Martijn wrote:
>> On Sun, Aug 30, 2009 at 6:53 PM, gperry<me@...> wrote:
>>> On 30/08/2009 16:15, Boris Zbarsky wrote:
>>>
>>>> That said, do you have specific numbers/examples to support your
>>>> "bloated" assertion?
>>> FF is currently at 150meg, it'll 300 before long and I'll have to close.
>>> Those figures are normal for FF atm.
> doing what?
> not saying this to be defensive. detailed and specific examples and test
> beyond what you list below is what we need to take actionable steps.

Normal browsing over the course of a few hours, with never more than 3
or 4 tabs open. Sites include ebay, some php and vbb forums and some
blogs, normal stuff, normal use. Now at 150 meg again, after having
restarted it about 10 minutes ago. It starts at 50meg rises quickly,
stays at about 150, then on occasional feature rich page it'll go to
300, and important it never sheds the memory when you navigate away.

(while I was typing this, thunderbird seized up, whited out and become
unresponsive to key presses for 30 seconds. 30 secs after that, my
remote calendars events redrew on the today page.)

>>> TB and Lightning are 160meg. Outlook is running along side it with
>>> the same
>>> imap accounts and remote calendars and it's just over 35meg (and it's
>>> way
>>> faster).
>>>
>>>
>>> For that matter, do you have specific issues that
>>>> you describe as "slow"? A general "slow" is not an actionable item.
>>>>
>>>> -Boris
>>> -Page laods are slow in FF, slower than even IE. Chrome and Opera
>>> make FF
>>> look like a joke.
>>>
> which "pages"?
> by how much?

Every page. Some times it appears to load faster, but the time taken
before the page actually becomes available to me to scroll etc, is much
longer. This is again down the the sheer cpu resources that FF needs to
load a page.
>>> -javascript performance is horrible
> on which bench mark or page?
>>> -When pages are loading, the rest of the interface is unresponsive.
>>> In fact
>>> is takes so much processor priority as too jam up the entire operating
>>> system.
> which pages? good test cases needed/wanted.
Again, every page, compare page loads in FF to opera, chrome and IE,
you'll see cpu hit 80-90% on every page in FF, while the rest barely
break a sweat.
>>> -'complex' webpages jam up the browser, leading to slow scrolling and
>>> slow
>>> inteface. By 'complex' I mean a little bit of javascript or an image
>>> table
>>> with a few effects, or some text decoration here and there.
>>>
> which pages or test cases show this? can you point at one or put one
> together?
Next time I come across one I'll post it here.

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T11:07:07Z

On 30/08/2009 18:08, Martijn wrote:

Yes, I expected that kind of form response.
Extensions/safemode/hardware. Blame everything but the actual app. This
kind of response is the default on every forum and support group. It's
tiresome and patronizing.

fwiw, extensions running are adblock plus, dom inspector, autofill
forms, add bookmarks.. there are a few, but it doesn't make any
different whether they are running or not. The behavior is part of FF,
not the addons. I'm not so stupid that I haven't ruled these out.
The hardware is a 3.2ghz HT pentium on W7 with 2gig. It's plenty fast
enough for what should be a simple web browser. It runs photoshop and
dreamweaver, side by side, faster than FF on its own.
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T10:18:21Z

Martijn wrote:

> On Sun, Aug 30, 2009 at 6:53 PM, gperry<me@...> wrote:
>
>> On 30/08/2009 16:15, Boris Zbarsky wrote:
>>
>>
>>> That said, do you have specific numbers/examples to support your
>>> "bloated" assertion?
>>>
>> FF is currently at 150meg, it'll 300 before long and I'll have to close.
>> Those figures are normal for FF atm.
>>

doing what?

not saying this to be defensive. detailed and specific examples and
test beyond what you list below is what we need to take actionable steps.

>> TB and Lightning are 160meg. Outlook is running along side it with the same
>> imap accounts and remote calendars and it's just over 35meg (and it's way
>> faster).
>>
>>
>> For that matter, do you have specific issues that
>>
>>> you describe as "slow"? A general "slow" is not an actionable item.
>>>
>>> -Boris
>>>
>> -Page laods are slow in FF, slower than even IE. Chrome and Opera make FF
>> look like a joke.
>>
>>

which "pages"?
by how much?
>> -javascript performance is horrible
>>
on which bench mark or page?
>> -When pages are loading, the rest of the interface is unresponsive. In fact
>> is takes so much processor priority as too jam up the entire operating
>> system.
>>
which pages? good test cases needed/wanted.
>> -'complex' webpages jam up the browser, leading to slow scrolling and slow
>> inteface. By 'complex' I mean a little bit of javascript or an image table
>> with a few effects, or some text decoration here and there.
>>
>>
which pages or test cases show this? can you point at one or put one
together?

>> -It takes over 3 minutes for thunderbird and lightning to start up, and they
>> are unresponsive during that time. remote calendars reload multiple times,
>> windows will white out the window as it becomes un responsive (multiple
>> times), cpu usage will get stuck at 50%+, it slows downs the rest of the OS,
>> it's only in the last minute or so that it actually starts pulling down
>> email.
>> -after it's loaded, lightning is still painfully slow. every page scroll
>> requires multiple, intensive calendar redraws/refreshs
>> -despite having spent so long starting up, it still doesn't pull down rss
>> feeds at start up, instead leaving it 5-10minutes after startup.
>>
>>
>> The list goes on. And they are all obvious and well known ones. The fact
>> you'd even have to ask means that, if you are a developer, you are a badly
>> out of touch one.
>>
>> I read through these dev forums excepting to see performance being at the
>> very top of the agenda, seeing as how firefox made it's name on being fast
>> and it is now almost as slow as IE (and in some respects slower), but a
>> cursory glance tells me that the devs are far more concerned with a fancy
>> new UI.
>>
>
> Do you have any extensions installed? Do you use a different theme
> than the default one?
> What cpu speed do you have?
>
>

what operating system?

-chofmann

> Regards,
> Martijn
>
>
>> _______________________________________________
>> dev-performance mailing list
>> dev-performance@...
>> https://lists.mozilla.org/listinfo/dev-performance
>>
>>
>
>
>
>

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T10:14:40Z

On 30-Aug-09, at 1:08 PM, Martijn wrote:

> Do you have any extensions installed? Do you use a different theme
> than the default one?
> What cpu speed do you have?

If these are the problems the user should go to http://support.mozilla.com

My impression is that while well-intentioned, we're just feeding a
troll here. Let's not.

cheers,
mike
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T10:08:06Z

On Sun, Aug 30, 2009 at 6:53 PM, gperry<me@...> wrote:

> On 30/08/2009 16:15, Boris Zbarsky wrote:
>
>> That said, do you have specific numbers/examples to support your
>> "bloated" assertion?
>
> FF is currently at 150meg, it'll 300 before long and I'll have to close.
> Those figures are normal for FF atm.
> TB and Lightning are 160meg. Outlook is running along side it with the same
> imap accounts and remote calendars and it's just over 35meg (and it's way
> faster).
>
>
> For that matter, do you have specific issues that
>>
>> you describe as "slow"? A general "slow" is not an actionable item.
>>
>> -Boris
>
> -Page laods are slow in FF, slower than even IE. Chrome and Opera make FF
> look like a joke.
> -javascript performance is horrible
> -When pages are loading, the rest of the interface is unresponsive. In fact
> is takes so much processor priority as too jam up the entire operating
> system.
> -'complex' webpages jam up the browser, leading to slow scrolling and slow
> inteface. By 'complex' I mean a little bit of javascript or an image table
> with a few effects, or some text decoration here and there.
>
> -It takes over 3 minutes for thunderbird and lightning to start up, and they
> are unresponsive during that time. remote calendars reload multiple times,
> windows will white out the window as it becomes un responsive (multiple
> times), cpu usage will get stuck at 50%+, it slows downs the rest of the OS,
> it's only in the last minute or so that it actually starts pulling down
> email.
> -after it's loaded, lightning is still painfully slow. every page scroll
> requires multiple, intensive calendar redraws/refreshs
> -despite having spent so long starting up, it still doesn't pull down rss
> feeds at start up, instead leaving it 5-10minutes after startup.
>
>
> The list goes on. And they are all obvious and well known ones. The fact
> you'd even have to ask means that, if you are a developer, you are a badly
> out of touch one.
>
> I read through these dev forums excepting to see performance being at the
> very top of the agenda, seeing as how firefox made it's name on being fast
> and it is now almost as slow as IE (and in some respects slower), but a
> cursory glance tells me that the devs are far more concerned with a fancy
> new UI.

Do you have any extensions installed? Do you use a different theme
than the default one?
What cpu speed do you have?

Regards,
Martijn

> _______________________________________________
> dev-performance mailing list
> dev-performance@...
> https://lists.mozilla.org/listinfo/dev-performance
>

--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T09:53:19Z

On 30/08/2009 16:15, Boris Zbarsky wrote:

> That said, do you have specific numbers/examples to support your
> "bloated" assertion?
FF is currently at 150meg, it'll 300 before long and I'll have to close.
Those figures are normal for FF atm.
TB and Lightning are 160meg. Outlook is running along side it with the
same imap accounts and remote calendars and it's just over 35meg (and
it's way faster).

For that matter, do you have specific issues that
> you describe as "slow"? A general "slow" is not an actionable item.
>
> -Boris
-Page laods are slow in FF, slower than even IE. Chrome and Opera make
FF look like a joke.
-javascript performance is horrible
-When pages are loading, the rest of the interface is unresponsive. In
fact is takes so much processor priority as too jam up the entire
operating system.
-'complex' webpages jam up the browser, leading to slow scrolling and
slow inteface. By 'complex' I mean a little bit of javascript or an
image table with a few effects, or some text decoration here and there.

-It takes over 3 minutes for thunderbird and lightning to start up, and
they are unresponsive during that time. remote calendars reload multiple
times, windows will white out the window as it becomes un responsive
(multiple times), cpu usage will get stuck at 50%+, it slows downs the
rest of the OS, it's only in the last minute or so that it actually
starts pulling down email.
-after it's loaded, lightning is still painfully slow. every page scroll
requires multiple, intensive calendar redraws/refreshs
-despite having spent so long starting up, it still doesn't pull down
rss feeds at start up, instead leaving it 5-10minutes after startup.

The list goes on. And they are all obvious and well known ones. The fact
you'd even have to ask means that, if you are a developer, you are a
badly out of touch one.

I read through these dev forums excepting to see performance being at
the very top of the agenda, seeing as how firefox made it's name on
being fast and it is now almost as slow as IE (and in some respects
slower), but a cursory glance tells me that the devs are far more
concerned with a fancy new UI.
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: considering how slow and bloated every mozilla app is..

2009-08-30T08:15:20Z

gperry wrote:
> ..I'm very surprised that this group is virtually empty.

Most performance discussion happens in bugs and on irc. This group is
not really used as a venue for communicating about performance issues
(and we should probably just get rid of it, I guess).

That said, do you have specific numbers/examples to support your
"bloated" assertion? For that matter, do you have specific issues that
you describe as "slow"? A general "slow" is not an actionable item.

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

considering how slow and bloated every mozilla app is..

2009-08-29T11:14:56Z

..I'm very surprised that this group is virtually empty.
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: Tag-Soup- versus XML-Parser

2009-07-11T22:29:22Z

[Please don't cross-post without setting followup-to; set that to
.performance]

Ernst Bauernfeind wrote:
> as I can see, there are at least to different methods of parsing a (x)
> html-document: a "tag-soup"-parser which is very error-prone and makes
> the best out of non-valid websites. and a xml-parser, which is only
> activated if a document is served with mime-type application/xhtml
> +xml.

You mean "error-correcting", not "error-prone", right?

> IMHO an xml-parser should be a lot faster, because it just stops if
> there is an error, and has not to concern error-handling.

It also needs to implement very different parsing rules from HTML in
general, keep track of namespaces, etc.

> I would be very interested in performance-comparison between the
> mostly used tag-soup-parser and the xml-parser for xhtml1.x documents
> which are correctly served as application/xhtml+xml.
>
> can you maybe give me any metrics?

Parser performance per se is more or less a wash, from what I've seen.
It's also generally been a small enough component of pageload time (15%
or less) that this aspect should be about the last factor in decidint
whether to use use XML or not.

> or, better, is it possible to extract the gecko document parser and
> benchmark it standalone with various documents?

Why? That would give you a somewhat useless number for your purposes
(see below).

> the answer to this question is relevant if it is preferable to build
> valid xml xhtml documents or just stick to html 4.01.

That's an entirely different question from a performance standpoint.
Typically, the HTML codepath receives more attention in terms of
optimization and profiling; if we have to sacrifice XHTML-as-XML
performance in favor of HTML performance, we do so.

There are also common markup constructs that actually do significantly
different things in XHTML-as-XML and in HTML. A good example:

<table>
<tr><td>Text</td></tr>
</table>

This produces different DOMs in HTML and in XHTML-as-XML; the HTML one
is faster to lay out, especially if you plan to do any dynamic addition
or removal of rows in that table.

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Tag-Soup- versus XML-Parser

2009-07-11T17:51:18Z

Hi folks,
as I can see, there are at least to different methods of parsing a (x)
html-document: a "tag-soup"-parser which is very error-prone and makes
the best out of non-valid websites. and a xml-parser, which is only
activated if a document is served with mime-type application/xhtml
+xml.
IMHO an xml-parser should be a lot faster, because it just stops if
there is an error, and has not to concern error-handling.

I would be very interested in performance-comparison between the
mostly used tag-soup-parser and the xml-parser for xhtml1.x documents
which are correctly served as application/xhtml+xml.

can you maybe give me any metrics?

or, better, is it possible to extract the gecko document parser and
benchmark it standalone with various documents?

the answer to this question is relevant if it is preferable to build
valid xml xhtml documents or just stick to html 4.01.

thank you very much!
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

NEED MONEY FAST READ THIS ARTICLE 90116

2009-04-28T08:24:37Z

NEED MONEY FAST? READ THIS ARTICLE

SPEND 5 MINUTES OF YOUR TIME AND YOULL SEE THIS REALLY WORKS AND BESIDES ITS LEGAL!!!

I was surfing by the groups (GOOGLE, YAHOO, ALTAVISTA, ETC.), when I saw an article saying something about earning money fast. Well -said to myself-, I have to see what kind of schematic can they show in internet. These article described the way of sending BY MAIL, 1 EURO OR AMERICAN DOLLAR TO JUST 6 PERSONS AND EARNING THOUSANDS OF DOLLARS IN 4 WEEKS. Okay, the more I thought about this, the more excited I as getting. It seemed a scam, but I was curious, so I kept reading. After meditating it, I decided to give it a try. It is really worth just 6 euros, or 6 U.S. dollars and 6 postage stamps, I spent more buying lottery and I've never won. This is not a scam; is not indecent, is not illegal, and is 99% freerisk, it really works if you adhere to the instructions, you will receive extraordinary dividends.

I must also tell you that this system has fulfilled its natural cycle, in other words, has proven its effectiveness and excellent results. Also, this system does not require physical contact with people, nor requires a heavy duty or difficult and the best: you do not have to leave home except to collect their mail. This is a program that uses the electronic medium Global Internet platform, which ensures its operation in perfect shape. 100% OF THE TIME.

Thousands of people have used this way to get good capital and start their own business. Basically, it is possible through a chain that is lead to thousands of people and that will become a reality for you only with your cooperation. That's why I recommend you carefully follow EXACTLY THE INSTRUCTIONS OF THIS LETTER, saying once more that this is 100% safe and that you will not regret having read this article and putting it in practice ... SHARE AND RECEIVE MONEY FAST ... BY MAIL. THIS REALLY WORKS

INSTRUCTIONS

STEP 1.
· Get 6 sheets of white paper and write: "PLEASE ADD MY NAME TO YOUR LIST. Then, write your own name, address and e-mail. And as a nice thing also write in what position was every name of people when you sent your DOLLAR OR EURO (eg "You were in slot 3), so you can make it more complete.The goal is to make money and have a good time at the same time, all with good. will.
· Now bend the page where you have written the above around the 1 Euro coin or 1 U.S. dollar bill. Do not sent checks or other payments, only Euros or American Dollars.
· Put it all inside an envelope and send it to each one of the 6 persons listed, the idea of doubling the paper over the Euro is to ensure that it will arrive at its destination so that is an important thing. Otherwise the people who works in the mail could detect that there is money inside and they could get the thousands of incoming envelopes, so it is recommended to wrap everything, additionally, in a charcoal paper so noone could see through the envelope.
· What we're doing is creating a service and as such, it is COMPLETELY LEGAL. From now on, you are not sending a EURO or one dollar to any person without any grounds, you are paying An EURO or DOLLAR for a legitimate service. Then you must send the 6 envelopes to following addresses:

1) Mario Jose Cardozo Matute
Sector OPS El Picacho Calle Venezuela,
Urb. Trebol Country Edf. Altamira piso PB Apto C.
Edo. Miranda Mpio. Los Salias, San Antonio de los Altos
C.P. 1173, Venezuela.

2) Marcos Gonzalo Lopez
San Luis 312 B 9 de Julio
Palpala, Jujuy, Argentina C.P.4612

3) Jorge Luis Munoz Garcia
Bernardo Alcedo 197 Dpto. 403
Santa Cruz Miraflores Lima, Peru C.P. Lima 18

4) Edgar Jorge Nava Arambula
Carranza #500 zona centro
Villa Union, Poanas Durango, Mexico
C.P. 34803

5) Gildardo J. Villarreal
709 Concord St.
Aurora, Il. 60505 USA

6) José L. Salgado
Av. De Las Palmeras N46-384 y Madroños
Provincia: Pichincha
Quito - Ecuador

STEP 2.

Listen carefully, this is the way how are you going to receive money by mail. Look at the list of the six people, clear the name # 1 in the list above, and add yours at the end of it, so the # 2 becomes # 1 and the # 3 becomes # 2, the # 4 becomes # 3 and the # 5 becomes 4 and so on. So you are now the number 6, include your name, address, postal code, city, state and country.

STEP 3.

Change everything you think is useful on this article, but try to keep as close as possible to the original. Now put your article at least 200 newsgroups, forums, classified or free ads, and publicate it (To reach them, just put into any search engine these terms: newsgroups, discussion forums, classified ads or free guestbooks, and thousands of pages will appear). You only need 200, but the more numbers you get, the more you will be sent to you.

Here are some Indications of how to break into Newsgroups: HOW TO MANAGE NEWSGROUPS: First, you dont need to write again all this letter to make it yours. Just put the mouse or mouse cursor at the beginning of this letter and select downwards so all the text will be "shady". Then, press CTRL+C. This way it remains in the memory of your computer. Then open an application preferably NOTEPAD Wordpad or Word. Then, once opened any of these Applications place your cursor at the beginning of a blank sheet of paper and Pressing CTRL+V, so you'll have this letter and you can add your name and address in the # 6 by following the instructions above. At Last, save this letter with your changes into a new file in the application. THATS ALL. All you have to do now is get in different newsgroups, forums, classified or free ads, and so on. and publicate it.

REMEMBER: DO NOT forget to publish the entire notice or letter with your name on the position 6, disappearing the one which has the number 1; when you acquire practice, itll only take you about 30 seconds per newsgroup

It is further recommended that when publishing the description of this article to give it a "trapping name", like: "NEED MONEY FAST? READ THIS ARTICLE" or "NEED MONEY TO PAY YOUR DEBTS? "," DOWNLOAD THIS FILE AND READ HOW YOU CAN RECEIVE MONEY BY MAIL "and so on. And do not name it: "WIN MILLION IN 1 WEEK",because nobody will take you seriously.

READY! You're getting money from around the world, from places you dont even know in a few days. MAKE SURE ALL ADDRESSES ARE CORRECT ** Now the WHY of all this: from 200 notices sent, lets say you only get 5 replies (a very low example).
If only 6 people respond, this makes:
In the # 6: 6 Euros (U.S. $) In # 5: 36 Euros (U.S. $) In the # 4: 216 Euros (U.S. $) In # 3: 1296 Euros (U.S. $) In the # 2: 7776 Euros (U.S. $) In # 1: 46,656 Euros (U.S. $)

LAST STEP.

And this is the step I like JUST SIT DOWN and when you begin to fall short of money, reactivate it and file re-publish this file in the same places where you are going to do it now and new places youll know in the future. Always keep on hand a copy of this article, REACTIVATE IT every time you need money.. THIS IS AN UNBELIEVABLE TOOL THAT YOU CAN USE AGAIN EVERY TIME YOU NEED CASH, IT IS AN EXTRAORDINARY WAY OF SHARING AND IN WHICH WE ATTRACT WEALTH TO OUR LIVES. HONESTY IS WHAT MAKES THIS PROGRAM SUCCEEDS. DO NOT FORGET IT!
GOOD LUCK!

Just one more point, if you translate all this message to other
languages, you can also paste it in various newsgroups of many countries,such as
France, Germany, Russia (I say this as a tip to expand chances of seeing it by a lot more people).

Z@FNk%yYJ=tBC#wWLnGBlVqjX

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

autocad electrical 2010 autodesk full download crack torrent rapidshare 01601255

2009-04-11T17:35:59Z

email = xshowsoft@...
email = xshowsoft at gmail.com

autocad electrical 2010 full download crack torrent rapidshare
autocad electrical 2010 download
autocad electrical 2010 crack
autocad electrical 2010 full download
autocad electrical 2010 torrent download
autocad electrical 2010 torrent
autocad electrical 2010 rapidshare
autocad electrical 2010 megaupload
autocad electrical 2010 autodesk

email = xshowsoft@...
email = xshowsoft at gmail.com

Artpro 7.6. Rev. 4 k[ed]

Artpro 8.1 k[ed]

Artpro 9.0 rev. 1 build 2

CREO (Kodak) Preps v5.3.2

Founder ElecRoc v4.626

Onyx ProductionHouse v7.1

EFI colorproof k[ed] PC only

Esko Deskpack V7. r4 Mac only

Esko Softwares Suite V7. r4. PC/Mac all options enabled

Esko Ripmate V7

Heidelberg Prinect Workflow 4.0.540 included:

- PrintReady 4.0

- Prinect Prepress Manager

- Prinect Postpress Manager

- Prinect Pressroom Manager

- Prinect Production Manager

- Prinect Cockpit 4

- Analyze Point 4.0.394.1

- JDF Connector Service 4.0.394.1

- JDF Storage Service 4.0.394.1

- JMF Message Service 4.0.394.1

- Master Data Service 4.0.394.1

- Service Tools

Heidelberg DeltaRIP 8.5

Heidelberg PDF Toolbox v4.0

Heidelberg SignaStation v4

Others:

ACC HSH Group PDF Tools 2.4

ACC HSH Group PuzzleFlow 2.3

Acrobotics PDF-SuperTool 1.0

Advanced PECOM 2.9

AGFA Apogee Create 1.0 Series 2 & 3

AGFA Apogee Cristal Raster 2.5

AGFA Apogee PDF RIP 2.0 Update 6 Series 3

AGFA Apogee Pilot 1.0

AGFA Apogee PrintDrive 1.0 Series 3

AGFA Apogee Taipan RIP 3.1

ALAP Imposer Pro 1.1.1 (InDesign plugin)

Apago PDF Enhancer 2.6

Apago Piktor 3.0

ARTS Split Pro 1.3.1

Artwork Systems Nexus 7.5

Artwork Systems ArtPro 7.5 (MAC)

Aurelon Signalize! RIP 5.7.0

BasICColor Catch 2.50

BasICColor Dcam 2.0.1

BasICColor Display 3.0.3

BasICColor Print3c 2.0.2

BasICColor Print4c 2.0.2

BasICColor Scan Plus 2.0.1

BasICColor Server 1.1.0

BrainNew EconoInk 1.3.7

BrainNew ImageHarbor PostRIP Imposition 5.01

CADlink SignLab 7.1

Cadvantage Win Printex 5.0

CGS ORIS Certified Proof 1.2

CGS ORIS Color Tuner 5.1.2

CGS ORIS PDF Tuner 4.2.6

CHROMiX ColorThink 2.1.2

ColorBlind Professional 5.1.3

ColorBurst RIP 7.50

ColorFacts Professional 5.50 - NEW

ColorGATE PhotoRIP 3.8.4.613

ColorGATE PHOTOGATE 4.05

ColorGATE PRODUCTIONSERVER 4.06 (with FILMGATE)

ColorGATE PROOFGATE 4.05

ColorGATE Screen & Sign 3.8.4.613

ColorMetrix ProofPass 1.8.10 + Trending 1.1.4

ColorSpan ColorMark Legacy SW RIP 8.82-LSR

ColorSpan ColorMark PRO SW RIP 8.94

Colour Chameleon 2.0

Colour Matters CM32 3.24

Colorbytesoftware ImagePrint 5.6

Compose Express Colorflow 1.01 + all components

Compose Express Flatout Express 2.2

Compose Express PDF Imposition 4.0

Compose Express Plate Controller 1.3

Compose Express PRI Station 2.1

Compose Express Raster PrintStation 2.2

Compose Express Workflow 2.4

Creo CopyDot ToolKit 4.0

Creo Pandora 2.7

Creo Preps 5.1.2 (PC & MAC)

Creo Print Console 3.5

Creo Prinergy 3.0.2.1

Creo PS/M 7.1, 8.0 (for MAC)

Creo Synapse Prepeare Pro 1.1 (for MAC)

Creo TrapWise 3.6

CSIP Printer System 1.01

Dainippon SCREEN PixelStream 4.6 (Impos2000 Server, InkProof)

Dainippon SCREEN SPEKTA 6.x

Devstudio Power Plotter 5.4.26

DGS MatchPrint II 4.05

DGS Portrait 2 3.31

DGS Ramsete III 8.55

DigiFab Systems Evolution RIP 3.2.5.8

Digital Light & Color Profile Mechanic-Sanner 1.0.0.3

Dynagram DynaStrip 4.4.0

Ergosoft PosterPrint 11.0.1

Ergosoft StudioPrint 11.0.1

Ergosoft TexPrint 11.0.1

ECRM MAXWorkFlow 3.5 (all modules)

EFI BEST ColorProof 5.0.1 SP2 (XXL and Laser)

EFI BEST PhotoXposure XXL 5.0.1 SP2

EFI BEST ScreenProof 5.0.1 SP2 (Full and 4UP)

EFI BEST Premium Addon 1.1.0

EFI ColorProof XF 2.6.1 SP1 - NEW

Enfocus Instant PDF 3.02 (Acrobat plugin)

Enfocus PitStop Server 3.0

EFI ColorProof XF 3.1

ESKO-Graphics FlexoPERfection 7.0

ESKO-Graphics ArtiosCAD 6.02

ESKO-Graphics ColorTone 2.1

ESKO-Graphics ColorQuartet Pro 5.2.2

ESKO-Graphics BackStage 2.0 (standalone)

ESKO-Graphics BackStageEdit 4.0

ESKO-Graphics DeskPack Adoble Illustrator client for BackStage 1.2/2.0

ESKO-Graphics FlexoPERfection 3.2.08 - NEW

ESKO-Graphics FlexRIP 5.2

ESKO-Graphics FlexRIP Pilot 2.0 (like BackStage 2.0 but needs FlexRIP)

ESKO-Graphics PackEdge 4.0

ESKO-Graphics Plato 4.0

ESKO-Graphics RipMate 5.1

EUROSYSTEMS Pjannto RIP 1.4.3

ExtremeZ-IP 4.0.4x17

Eyes3D 1.0

EngView Synergy 3.6.15

EUROSYSTEMS CoCut 11 Pro

EUROSYSTEMS EuroCUT 6.0.40 Pro

EUROSYSTEMS SmartCUT 6.0.44 Pro

Express Digital Darkroom Assembly Edition 8.61

Express Digital Darkroom Professional 8.61

FastFilms 3.5 (Photoshop plugin)

FastRIP Regular/Pro/LF 8.0

Flip! Super 3D Genius 1.5

Franklin Estimator 4.04

Founder EagleDot 3.5

Founder EagleProof 3.5

Founder EagleRIP 3.0 (build 3418)

Founder EagleRIP 4.0 + EagleFAM 1.0

Founder EagleRIP V8 + EagleFAM 1.0

Founder SuperLine 4.03 (Chinese)

FotoWare Color Factory 3.1

FotoWare Distribution Manager 4.0

FotoWare FotoWeb 2.5

FotoWare Index Manager 4.5

Fuji ColourKit Profiler Suite 4.2

GMG Colorproof 3.3.75

Graphx RasterPlus 5.2.12

GretagMacbeth Color Quality 3.6

GretagMacbeth Color iMatch 3.64

GretagMacbeth iCPrint 1.2.0

GretagMacbeth iQueue 1.1.5

GretagMacbeth Ink Formulation 5.01

GretagMacbeth KeyWizard 2.5

GretagMacbeth MultiColor Separation/Proof 1.2 (Photoshop plugin)

GretagMacbeth ProfileMaker Pro 5.0.4 (PC & MAC)

GretagMacbeth ProPalette 5.2.3.1

GretagMacbeth SpectoChart 1.21

GretagMacbeth TabWizard 1.0

Gerber Scientific OMEGA 2.1 - NEW

Husqvarna Viking VIP Embroidery System 6.2

Koppermann Tex-Define 6.0 - FULL CD

Koppermann Tex-Design 6.0 - FULL CD

Koppermann Tex-Store 6.0 - FULL CD

MOST Visual Studio - Artist 3.3

MOST Visual Studio - Coloring & 3D 5.99

MOST Visual Studio - Dobby 5.99

MOST Visual Studio - Design 5.16

Harlequin Compose Express RIP 7.0

Harlequin ECRM RIP 6.4

Harlequin HighWater Designs Torrent RIP 7.0

Harlequin Dainippon HQ-510PC SCREEN 6.4

Harlequin JET RIP 5.51a

Harlequin RTI RIP-Kit 6.2

Harlequin Xitron Navigator RIP 7.0

Harlequin Xitron SDP-RIP 6.0

Heidelberg Delta Technology 8.2 - NEW

Heidelberg PDF Toolbox 2.0.38 (Acrobat plugin)

Heidelberg Prinect Profile Toolbox 1.1 (PrintOpen 5.1 + QualityMonitor 1.1)

Heidelberg Prinect Signa Station 1.5.2

Heidelberg PrepressInterface 3.2 - NEW

Heidelberg SignaStation 9.0.4 OLD

Heidelberg MetaDimension 5.2 - NEW

Heidelberg MetaShooter 2.2 - NEW

Heidelberg NewColor 7000 2.0.0

HighWater Designs Herkules Calibration Tool 1.0

HighWater Designs HWRoam 1.3

HighWater Designs InkMonitor 3.3.1

HighWater Designs PixelProof Print Server 1.3

HighWater Designs Q2 Output Controller 4.1.3

Heidelberg Delta Technology 8.2

Heidelberg MetaDimension 5.2

Heidelberg MetaShooter 2.2

Howtek Trident Drum & 2500 Scanner 3.7.1

Imposition Publisher 4.6.4 (PC & MAC) - NEW

iProof PowerRIP ImageSet 7.2.5

iProof PowerRIP SilkScreen 7.2.5

ISITooolbox 5.0.02 build 4001 (Acrobat plugin)

KODAK Professional Digital Print Production Software 5.1.27

KoreaSoft Artist RIP & Cut Pro 9.0

Krause Imposition Manager PDF 5.0.0

Kimoto AttractProof 3.5

LaserSoft SilverFast 6.4.1r2

MonacoDCcolor 1.0.0

MonacoEZcolor 2.5

MonacoPROFILER 4.6.1 Platinum (MAC)

MonacoPROFILER 4.8.0 Platinum - NEW

MonacoPROOF 3.7.1

Nfive Cardfive 6.3

ODESSA LaserPROOF 3.3.0.6

Onyx PosterShop 6.0

Onyx ProductionHouse 6.0 SP2 (all printers)

PANTONE ColorDrive 1.5

PANTONE ColorVision ProfilerPRO 3.0.1 (Photoshop plugin)

PANTONE HexWare 2.5 (Illustrator/Photoshop plugin)

PerfectProof ProofMaster 2.0.7

Phase One C1 PRO 3.5

Plug-In Systems Packagizer 1.199

PosterJet RIP 6.5.7

PrePRESS Panther RIP 10.4

PrePRESS Panther PageImposer 10.3

PrintShop Mail 5.0.6

PrintSmith 6.3.2

PolyPattern 3.5v3

Q-Enhancer 2.1

RIPit OpenRIP Workflow 2000 3.0

RPM Remote Print Manager 4.5

ScanvecAmiable PhotoPRINT Server Pro 4.6v2

ScitexVision PressJet 2.6.1

Septone 7.0 Release 1.4 (Photoshop plugin)

Seagull BarTender 7.72

Serendipity BlackMagic 3.1 - NEW

Serendipity Megarip 4.1 - NEW

Shiraz RIP 6.0

ThunderStorm RIP Pro 6.40 (Korean)

TECHKON ExPresso 2.1

Teklynx CODESOFT 7.10

Ultimate Impostrip 8.1.0.4

Ultimate Impostrip On-Demand 4.2.0.0

Wasatch SoftRIP 5.1.5 - NEW

Wincomsoft RipMaster 1.230.4.729

ScanvecAmiable FlexiSIGN Pro 7.6v2

ScanvecAmiable Inspire 1.6

SGS OptiTex 9.20

Smart Designer 12

Tajima DG/ML by Pulse X 11.0.5.2633 - NEW

USM2 1.14 - 2D Grading/Engineering

USM3 1.04 - 3D Shoe Design

Wilcom ES-65 9.0S SP4

WingsXP 1.50.2002.29

Colorave Imaginator 7.6.2

ConeTech Piezography BW Pro24 4.2.0

ISIS Photoi Mini KIOSK (DigiCube) 1.0

ISIS Photoi Minilab 1.6

Master Flex D Minilab & Workstation 3.0.138

Micro-Art Imaging Composite 5.0

PhotoLynx Solutions 1.6 - CamLynx 4.0

PhotoLynx Solutions 1.6 - PhotoLynx ImageMatch 6.0

PhotoLynx Solutions 1.6 - PhotoLynx ProComposites 6.1

PhotoLynx Solutions 1.6 - PhotoLynx ProServices 6.0

PhotoLynx Solutions 1.6 - PhotoLynx School Image Software (SIS) 5.5

Timestone Software - CapturePost 2.6.0

Timestone Software - Collate 2.2.0

Timestone Software - CompositeBuilder 1.0.0

Timestone Software - DataPost 2.6.1

Timestone Software - NeoComposite 2.4.0

Timestone Software - NeoGroup 2.5.0

Timestone Software - NeoPack Professional 2.8.0

Timestone Software - OutPost 1.4.0

Timestone Software - PrintTime 1.11.0

Timestone Software - RIPTime 1.7.0

Ultimatte AdvantEdge 1.6.0 (plugin)

Wasatch SoftRIP 5.1.5

X-Rite ColorShop 2.60

X-Rite PULSE ColorElite 1.0.2

Xinet FullPress 11.0.5

Xitron Raster Blaster 3.7

Xitron Xaps 2.1.3

Xitron XiFlow 2.5.0 - NEW

ZBE WorkStream Digital Studio 2.1

email = xshowsoft@...
email = xshowsoft at gmail.com

i2@Sf#1Lae3^Slg iSD,F:g@k!XML&d&1&J\1$+B
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

0.663362 Look Inside And Realize That Dream ... 0.8530349

2009-04-10T14:27:20Z

0.7528577 Look Inside And Realize That Dream ... 0.3189683

0.663362 Now Visit Tobacco Is Drugs 0.8530349

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

0.019633 See What's In Here ... 0.278576

2009-04-03T22:55:10Z

0.0329054 See What's In Here ... 0.7699172

0.019633 Now Visit http://nowclickhere.bravehost.com/index.html 0.278576

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

0.9107754 I Feel Curious ... 0.511521

2009-03-29T16:41:03Z

0.9748634 I Feel Curious... 0.319257

0.9107754 Now Visit http://www.clicklinknow.com/dating/ 0.511521

_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: FF3.1beta3 in Peacekeeper performance test

2009-03-14T18:42:32Z

Mike Cramer wrote:
> Has anyone an explaination why FF3.1 performs so poor in this test,
> because sofar I saw only tests where FF3.1 was only faster or fast as
> chrome.

Oh, and the key here is that you must have been looking at JavaScript
performance tests, whereas this thing is mostly not testing performance
of the JavaScript language itself.

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: FF3.1beta3 in Peacekeeper performance test

2009-03-14T18:41:36Z

Mike Cramer wrote:
> "..Peacekeeper measures your browser's performance by testing its
> JavaScript functionality. ..."

That's not what it tests.

> The following features are tested:
> http://service.futuremark.com/peacekeeper/faq.action

Right.

> As result they show this
> http://www.heise.de/mobil/Neuer-Benchmark-fuer-Internetbrowser--/zoom/134567/0

Which is semi-meaningless, since they don't ever explain how they
compute those numbers.

> which means that FF 3.1b3 is only ~1/2 as fast as safari 4.0

No, it means their scoring function, which they never explain, assigned
it half as high a score. What that means in practice depends on what
that function is. If you can get them to tell you that, I'd love to
know the results.

> I tried this test on my mac pro (2,4ghz, 4gb) and I got the following
> results:
> Safari 3.2.1 791points
> FF3.1beta3 592points

Which means what?

> Has anyone an explaination why FF3.1 performs so poor in this test

It's pretty easy to write tests on which FF3.1 performs worse than
Safari 4 (e.g. dromaeo). If you want me to explain numbers that are
being computed by some hidden formula, I think you're out of luck. ;)

For what it's worth, I spent a few hours on Friday trying to get this
test suite into a shape where I could run one test at a time (and hence
profile the tests to see where we spend time). I gave up when I
couldn't even get any of the tests but the array tests from their web
server: either they send different tests for the same URI based on
cookies, or their code is cleverly obfuscated beyond my ability to
comprehend. Or both.

Given that they don't publish sub-scores for the parts of the benchmark,
don't provide their benchmark's tests in a way that can be read (much
less run individually), and don't explain how their final score is
computed from the sub-scores, the credibility of these folks is about 0
for me right now. They could just be making all the numbers up using a
random number generator; I have no way to tell.

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

FF3.1beta3 in Peacekeeper performance test

2009-03-14T08:05:34Z

Hi,

I follow the impressive performance improvements of FF very closely, but
today I saw a new performance test which I could not believe.
http://www.futuremark.com/pressroom/pressreleases/55300/

"..Peacekeeper measures your browser's performance by testing its
JavaScript functionality. ..."

The following features are tested:
http://service.futuremark.com/peacekeeper/faq.action

As result they show this
http://www.heise.de/mobil/Neuer-Benchmark-fuer-Internetbrowser--/zoom/134567/0

which means that FF 3.1b3 is only ~1/2 as fast as safari 4.0

I tried this test on my mac pro (2,4ghz, 4gb) and I got the following
results:
Safari 3.2.1 791points
FF3.1beta3 592points

Has anyone an explaination why FF3.1 performs so poor in this test,
because sofar I saw only tests where FF3.1 was only faster or fast as
chrome.

Regards,
Mike
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: memory leaks in extension

2009-02-27T03:49:33Z

Problem of the second part was missing NS_RELEASE. But I still don't
understand why my classes aren't in log from Bloat View.
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

memory leaks in extension

2009-02-26T10:54:03Z

Hello everybody,
I'm just finishing my extension and try to get rid of memory leaks.
According to source:
https://developer.mozilla.org/en/Debugging_memory_leaks
I should have my classes in log of bloat view. However I am not able
to find any of them (I have at least 5 that are used during the run).
Could anyone tell me what could be the problem? I'm implementing
nsISupports with NS_IMPL_ISUPPORTSn in all classes, so it shouldn't be
problem(with NS_IMPL_ADDREF,...) described in the page above.

Second problem is, that I have spent a day with looking for source of
following leaks connected to nsBaseURLParser (1 rem), nsStandardURL (2
rem), nsStringBuffer( 2rem). I can post here also log from bloat view,
make-tree.pl and from find-comptr-leakers.pl, but I'm not sure
wheteher it's a good place, so if it is and someone might be able to
help me I can do it later.
Tia

Sadko
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance

Re: THREADS Management XUL/FIREFOX

2009-02-17T19:58:14Z

Takis Psarogiannakopoulos wrote:
>> Looking at the CVS blame for that file (which you could have done
>> yourself, of course), points to that number being picked in
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=205726>, or rather being
>> added there. There's no justification given for the number. You'd have
>> to ask Darin for his reasons, assuming he remembers 5+ years thence, but
>> I suspect it was just a "not too big, not too small" number.
>>
> I already answered asking this without having seen this message

You said:

My primary question here is: why the number 8? Why eg 4 or 5 which
seems more reasonable. If the threads are spending so little time
active why having 8 laying around?

They don't usually lay around. If they're idle, we shut them down. If
they're around that means they're actually busy servicing DNS requests.

> Not clogging the process with unessecary lwps.

Please define "unnecessary"? And "clogging"? What's actually better
from a user-observable point of view?

> You only need to to create those if you really need them.
> If you dont they why you created them in
> the first place.? Is there is a preformance adavantage?

I'm not sure what you're asking here. There's absolutely a performance
advantage to parallelizing DNS requests if those requests are network-bound.

> On DNS resolver there is considerable stack cause you have to carry
> buffers around.

When you say "considerable" what sort of numbers are we talking about?

>> If a global limit is implemented, what should happen when someone needs
>> a thread and the global limit has been hit?
>
> If what you say its true and we allow to spawn threads arbitrarily then
> most possibly we have an issue really on the *real time* perfromance of
> the evolving firefox process!

Firefox isn't a realtime system. If you mean user responsiveness, then
extra threads are (so far) a win in terms of taking work that can happen
in the background and doing it there without tying up the event loop.
As long as synchronization between the threads is kept to a minimum,
there is no problem as far as I can see. What am I missing?

I agree that "too many" threads could cause contention for hardware
resources (the processor in particular), which could adversely affect
user responsiveness. We're not hitting this, from what I can see, and
numbers of cores are growing faster than our thread usage at the moment.

Oh, and no one is allowed to spawn threads "arbitrarily". If a module
needs to do work in the background it will typically create a single
thread for this work; there are a very few exceptions (like DNS and
networking) that use small threadpools because they often have very
parallel workloads.

> primarily kernel overhead of multiple threads.

Are we talking about very limited hardware with a really crappy kernel?
Because I don't seem to recall LWP overhead on Linux, say, being
particularly noticeable (and the thread overhead is even less on other
OSes, last I checked).

-Boris
_______________________________________________
dev-performance mailing list
dev-performance@...
https://lists.mozilla.org/listinfo/dev-performance