On 3 August 2017 at 23:12, Jim Blandy wrote:
>
> But my question wasn't, "is pre-reservation ever valuable?" but rather "is
> it valuable in this particular code?" My assumption is that most code isn't
> performance-sensitive, and so simplicity should be the priority.
>
> The code Alexis cited at
On Wed, Aug 2, 2017 at 7:58 AM, Ehsan Akhgari
wrote:
> Vector reallocations show up in profiles all the time, literally in more
> than half of the profiles I look at every day. If you examine for example
> the large dependency graph of https://bugzilla.mozilla.org/s
> how_bug.cgi?id=Speedometer_
On 8/2/17 11:18 AM, Nathan Froyd wrote:
In particular, the API of Sequence<> is constrained because it
inherits from FallibleTArray, which *only* exposes fallible
operations.
We should consider just fixing this.
The history here is that FallibleTArray and InfallibleTArray used to
bake the all
On Tue, Aug 1, 2017 at 12:31 PM, Alexis Beingessner
wrote:
> I was recently searching through our codebase to look at all the ways we
> use fallible allocations, and was startled when I came across several lines
> that looked like this:
>
> dom::SocketElement &mSocket = *sockets.AppendElement(fall
On 08/01/2017 08:16 PM, Jim Blandy wrote:
I have to ask: does anyone recall the benchmarks that showed that bounds
checks or vector reallocations were a measurable performance hit in this
code?
Extra needless bounds checks certainly have shown up in profiles, for an
example see https://bugzilla.
On Tue, Aug 01, 2017 at 05:16:54PM -0700, Jim Blandy wrote:
I have to ask: does anyone recall the benchmarks that showed that bounds
checks or vector reallocations were a measurable performance hit in this
code?
If we don't, we should just write simple, obviously correct code.
If we do, there s
I have to ask: does anyone recall the benchmarks that showed that bounds
checks or vector reallocations were a measurable performance hit in this
code?
If we don't, we should just write simple, obviously correct code.
If we do, there should be a comment to that effect, or something to convey
to r
On Tue, Aug 01, 2017 at 01:28:37PM -0700, Eric Rahm wrote:
Both AppendElements and SetLength default initialize the values, there's no
intermediate uninitialzed state. SetCapacity doesn't initialize the values,
but they're also not indexable -- we have release bounds assertions --
unless you try
Both AppendElements and SetLength default initialize the values, there's no
intermediate uninitialzed state. SetCapacity doesn't initialize the values,
but they're also not indexable -- we have release bounds assertions --
unless you try really hard.
nsTArray doesn't support emplace although it do
On Tue, Aug 01, 2017 at 12:57:31PM -0700, Eric Rahm wrote:
nsTArray has various Append methods, in this case just using the infallible
AppendElements w/o out a SetCapacity call would do the job. Another option
would be to use SetLength which would default initialize the new elements.
If we're tr
nsTArray has various Append methods, in this case just using the infallible
AppendElements w/o out a SetCapacity call would do the job. Another option
would be to use SetLength which would default initialize the new elements.
If we're trying to make things fast-but-safeish in this case, the prefer
On Tue, Aug 01, 2017 at 12:31:24PM -0400, Alexis Beingessner wrote:
I was recently searching through our codebase to look at all the ways we
use fallible allocations, and was startled when I came across several lines
that looked like this:
dom::SocketElement &mSocket = *sockets.AppendElement(fal
I don't think that anyone deliberately set out to write the code this way.
Likely this is fallout from the mass-refactorings in bug 968520 and related
bugs. I'd recommend working with poiru and froydnj to see if there's any
automated follow-up we could do to remove/improve this pattern.
On Tue, Au
TL;DR: we're using fallible allocations without checking the result in
cases where we're certain there is enough space already reserved. This is
confusing and potentially dangerous for refactoring. Should we stop doing
this?
-
I was recently searching through our codebase to look at all t
14 matches
Mail list logo
