On Thu, 31 Jan 2013 02:40:01 +0100, Robert Kaiser wrote:
> Robert Relyea schrieb:
>> Switching to SQLite would make this a non-issue.
>
> Is there a plan to do this? An open bug? Someone working on it?
>
> Robert Kaiser
Doesn't SQLite come with its own set of issues? I vaguely remember the
urlcl
As someone who's maintained a c++ scientific library (eigen.tuxfamily.org)
until 2 years ago:
- GCC >= 4.4 generated the fastest code of any compiler I tried when it
came out (MSVC, ICC, Clang); 4.5 was even better; I stopped tracking after
that. ICC had less bad auto-vectorization, but it was sti
Ehsan Akhgari wrote:
> Given the above, I'd like to propose the following long-term
> solutions:
1. Did we try escalating a support request to Microsoft regarding this issue? I
know it is kind of an odd thing, but it seems like if you are insistent enough
and/or pay enough money, Microsoft engin
On Sat, Feb 2, 2013 at 6:26 AM, Ehsan Akhgari wrote:
>
> Vladan performed the analysis on telemetry measures reported out of a Tp5
> run and the results seem to indicate that the performance of several things
> such as GC and CC, image decoding, page loading, session restore, search
> service init
On 2013-01-30 11:03 PM, Ehsan Akhgari wrote:
We then tried to get a sense of how much of a win the PGO optimizations
are. Thanks to a series of measurements by dmandelin, we know that
disabling PGO/LTCG will result in a regression of about 10-20% on
benchmarks which examine DOM and layout perfor
On 2/1/2013 1:51 PM, Daniel Veditz wrote:
> On 1/30/2013 8:03 PM, Ehsan Akhgari wrote:
>> It turns out that disabling PGO but keeping LTCG enabled reduces the
>> memory usage by ~200MB, which means that it's not an effective
>> measure. Disabling both LTCG and PGO brings down the linker's
>> virtu
On 1/30/2013 8:03 PM, Ehsan Akhgari wrote:
It turns out that disabling PGO but keeping LTCG enabled reduces the
memory usage by ~200MB, which means that it's not an effective
measure. Disabling both LTCG and PGO brings down the linker's
virtual memory usage to around 1GB, which means that we wil
(2013/01/30 11:21), ISHIKAWA, Chiaki wrote:
(2013/01/29 19:03), Julian Seward wrote:
From: "Chiaki ISHIKAWA"
I could allocate 6 GB to linux 64 bits images for ordinary program
execution on my PC
But debug build of TB with all the symbols and such causes the memory
usage (including the loading
On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote:
Ehsan Akhgari a écrit :
I don't have a lot of experience with mingw32, but to the best of my
knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit
support
Ehsan, did you forget that there would be no memory problem with
64-bits
Boris Zbarsky a écrit :
On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote:
The trouble with going 64-bits is that the jit would then see some
significant regression, for cache pressure/instruction set related
reasons
Do you have numbers here?
I'm aware of some regressions for things that involve
On 2013-02-01 10:52 AM, Jean-Marc Desperrier wrote:
Ehsan Akhgari a écrit :
I don't have a lot of experience with mingw32, but to the best of my
knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit
support
Ehsan, did you forget that there would be no memory problem with 64-b
Nathan Froyd a écrit :
Do you have examples that you can point to? I'm sure the GCC folks
would be interested in hearing about concrete examples...
OK, there was many examples with older GCC versions, but it's not
guaranteed to be still true with the newest GCC which had significant
enhancem
On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote:
The trouble with going 64-bits is that the jit would then see some
significant regression, for cache pressure/instruction set related
reasons
Do you have numbers here?
I'm aware of some regressions for things that involve traversing DOM
trees in
On 2/1/13 10:50 AM, Nathan Froyd wrote:
Do you have examples that you can point to?
This certainly used to be the case for Mozilla code at one point, but it
may be worth remeasuring. Lots of gcc (and MSVC, and Mozilla code)
changes since then.
-Boris
___
Ehsan Akhgari a écrit :
I don't have a lot of experience with mingw32, but to the best of my
knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit
support
Ehsan, did you forget that there would be no memory problem with 64-bits
MSVC PGO builds ?
The trouble with going 64-bi
- Original Message -
> cja...@gmail.com a écrit :
> > Currently the best option for mingw is mingw-w64 for that (besides
> > what the name suggests) supports both 32 and 64-bit targets. Also
> > it
> > works with any version of GCC newer than 4.4, AFAIR.
>
> The question here is about perf
cja...@gmail.com a écrit :
I don't have a lot of experience with mingw32, but to the best of my
>knowledge, it's based on older versions of gcc (4.6?),
>and lacks 64-bit support
Currently the best option for mingw is mingw-w64 for that (besides
what the name suggests) supports both 32 and 64-b
On 2013-02-01 8:51 AM, rvj wrote:
I use XUL for developing apps that operate like real devices (intended
for touch screen displays)
I simply need to allow a user to select a printer without conventional
system window popups
Please familiarize yourself with the changes being made in bug 6295
I use XUL for developing apps that operate like real devices (intended for
touch screen displays)
I simply need to allow a user to select a printer without conventional
system window popups
"Daniel Holbert" wrote in message
news:mailman.10890.1359656222.32706.dev-platf...@lists.mozilla
On Fri, Feb 1, 2013 at 4:54 PM, wrote:
> Where can we find the decoders for ff and mp4?
Firefox doesn't ship with an MP4 decoder. On the platforms where we
support MP4 files we use the platform libraries. The support for this
is in:
content/media/plugins
content/media/omx
content/media/wmf
medi
On 1/2/13 00:00, cja...@gmail.com wrote:
Also, stupid question time: is it possible to build on Windows with
GCC and/or clang?
Yes, even better, it's possible to build on Linux for Windows using GCC, see:
https://developer.mozilla.org/en-US/docs/Cross_Compile_Mozilla_for_Mingw32
It should be
21 matches
Mail list logo
