Experience shows that many users really, really like all the features of
Session Restore and that we can't easily drop any.
However, if you have references to websites that you haven't visited in
years, that's not normal. Either these websites are still opened in some
tab, or there is a bug in Ses
On Thursday, 26 June 2014 21:03:22 UTC+5:30, Tobias Besemer wrote:
> A new topic to move the discussions from the bugs to this group.
>
> Bug 669034 - (sessionRestoreJank) [meta] Re-architect session restore to
> avoid periodic freezes
> https://bugzilla.mozilla.org/show_bug.cgi?id=669034
>
> B
Something new to this ???
Greets, Tobias.
Am Dienstag, 1. Juli 2014 21:44:16 UTC+2 schrieb Tobias Besemer:
> Am Dienstag, 1. Juli 2014 14:05:39 UTC+2 schrieb David Rajchenbach-Teller:
>
> > Let's concentrate on Session Restore for the moment.
>
>
>
> OK, it was just because of the example an
Am Dienstag, 1. Juli 2014 21:22:17 UTC+2 schrieb Zack Weinberg:
> On 06/28/2014 08:12 AM, Tobias Besemer wrote:
>
> >
>
> > Forgetting closed pages - or the data to a page - would only be a
>
> > problem is a scenario like this: The user editing a large text in
>
> > a wiki, don't save it, cl
Am Dienstag, 1. Juli 2014 14:05:39 UTC+2 schrieb David Rajchenbach-Teller:
> Let's concentrate on Session Restore for the moment.
OK, it was just because of the example and the need for a "Journaled Storage"
...
> Adopting a Journaled Storage will let us decrease the total amount of
> I/O. Once
On 06/28/2014 08:12 AM, Tobias Besemer wrote:
>
> Forgetting closed pages - or the data to a page - would only be a
> problem is a scenario like this: The user editing a large text in
> a wiki, don't save it, close the page by mistake, close the
> browser without undo the close of the page, resta
Let's concentrate on Session Restore for the moment.
Adopting a Journaled Storage will let us decrease the total amount of
I/O. Once we have sufficiently fine-grained differential updates, either
Journaled Storage or Sqlite would allow us to change only a single tab
(or even a single attribute). B
Am Samstag, 28. Juni 2014 18:39:12 UTC+2 schrieb David Rajchenbach-Teller:
> I don't follow what you have in mind. Assuming that you suggest we move
> to sqlite, you seem to be suggesting that we should considerably
> increase the amount of I/O. Or do I misunderstand what you say?
At first it was
I don't follow what you have in mind. Assuming that you suggest we move
to sqlite, you seem to be suggesting that we should considerably
increase the amount of I/O. Or do I misunderstand what you say?
Also, readability of sqlite being better than that of json is quite
debatable.
Best regards,
Da
Am Samstag, 28. Juni 2014 16:45:39 UTC+2 schrieb Tobias Besemer:
> Am Samstag, 28. Juni 2014 14:42:40 UTC+2 schrieb David Rajchenbach-Teller:
>
> > See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
>
> > on the proposed Journaled Storage mechanism. This should bring down the
Am Samstag, 28. Juni 2014 14:42:40 UTC+2 schrieb David Rajchenbach-Teller:
> See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
> on the proposed Journaled Storage mechanism. This should bring down the
> number of writes by an order of magnitude.
I had a look at this bug ... i
Am Samstag, 28. Juni 2014 14:45:38 UTC+2 schrieb David Rajchenbach-Teller:
> Tobas, if you have an opportunity to perform a comparison, this would be
> an interesting piece of data.
Sorry, not yet ... :-/
___
dev-platform mailing list
dev-platform@lists.
Am Samstag, 28. Juni 2014 14:44:53 UTC+2 schrieb Tim Taubert:
> Tobias Besemer wrote:
> > It is not just a question of battery!
> > Too much writing accesses also harms the life-time of HDs or SSDs!
> Yup, that's why we're working on it. Clearing data on quit won't get us
> there as data accumulate
Am Samstag, 28. Juni 2014 14:45:38 UTC+2 schrieb David Rajchenbach-Teller:
> While we should and will reduce the total amount of I/O due to Session
> Restore, I must add that we have not attempted to compare it to the
> total amount of I/O due to cache access for instance. I would not be
> surprise
Am Samstag, 28. Juni 2014 14:42:40 UTC+2 schrieb David Rajchenbach-Teller:
> See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
> on the proposed Journaled Storage mechanism. This should bring down the
> number of writes by an order of magnitude.
Thx! I will try to study it ..
Tobias Besemer wrote:
> Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert:
>> Tobias Besemer wrote:
>>
>>> The amount of I/O is always a problem! E.g. for Notebooks in battery use.
>> Yes, of course. That is a known problem and we're working on it by
>> increasing the write interval when
While we should and will reduce the total amount of I/O due to Session
Restore, I must add that we have not attempted to compare it to the
total amount of I/O due to cache access for instance. I would not be
surprised if the cache caused several orders of magnitude more I/O than
Session Restore, in
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details
on the proposed Journaled Storage mechanism. This should bring down the
number of writes by an order of magnitude.
Cheers,
David
On 28/06/14 14:32, Tobias Besemer wrote:
> Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim
Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert:
> Tobias Besemer wrote:
>
> > The amount of I/O is always a problem! E.g. for Notebooks in battery use.
> Yes, of course. That is a known problem and we're working on it by
> increasing the write interval when running on battery and wor
Am Samstag, 28. Juni 2014 14:23:32 UTC+2 schrieb Tim Taubert:
> Tobias Besemer wrote:
>
> > The ss is necessary, when e.g. a user editing a large text in a wiki,
> > haven't saved that text yet, and closes this page as a mistake. So he can
> > go back / undo close and still have his un-saved tex
Tobias Besemer wrote:
> The amount of I/O is always a problem! E.g. for Notebooks in battery use.
Yes, of course. That is a known problem and we're working on it by
increasing the write interval when running on battery and working
towards a journaled storage.
As I said before, cleaning sessionsto
Am Samstag, 28. Juni 2014 14:03:38 UTC+2 schrieb David Rajchenbach-Teller:
> I am currently running benchmarks to find the influence of each part of
> Session Restore data on startup duration.
Thank you!
> The work is ongoing, but for
> the moment, I can confirm that closed tabs and closed windo
Tobias Besemer wrote:
> The ss is necessary, when e.g. a user editing a large text in a wiki, haven't
> saved that text yet, and closes this page as a mistake. So he can go back /
> undo close and still have his un-saved text ...
Yes, this was the reason why sessionstore was introduced years ago
Am Samstag, 28. Juni 2014 14:00:12 UTC+2 schrieb Tim Taubert:
> Why is the amount of I/O a problem for you exactly?
The amount of I/O is always a problem! E.g. for Notebooks in battery use.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
htt
OK, maybe we should first talk about what the ss is for, what he should do,
when it is used & so ...
The ss is necessary, when e.g. a user editing a large text in a wiki, haven't
saved that text yet, and closes this page as a mistake. So he can go back /
undo close and still have his un-saved t
I am currently running benchmarks to find the influence of each part of
Session Restore data on startup duration. The work is ongoing, but for
the moment, I can confirm that closed tabs and closed windows have
strictly no measurable influence on startup duration. The ongoing work
towards differenti
Tobias Besemer wrote:
>> What problems are you currently hitting that you think will be fixed by
>> downsizing sessionstore.js?
> I have ~4-8 GB I/O because of ss on a 8h day. Please look at the bugs you
> have commented before.
I looked at those bugs and they don't have better problem descriptio
Am Samstag, 28. Juni 2014 08:04:43 UTC+2 schrieb Tim Taubert:
> To properly set the stage for this discussion, why exactly do you want
> this? Where do you see the problem with a "big" sessionstore.js file?
Bug 669034 - (sessionRestoreJank) [meta] Re-architect session restore to avoid
periodic fr
Am Samstag, 28. Juni 2014 07:28:22 UTC+2 schrieb Katelyn Gadd:
> If this behavior were changed I'd change it back locally with a pref
> or addon or something.
This should be the solution for those who want this behavior.
> There are lots of reasons to exit (powering off to install
> windows upda
> I often restart FF because of memory use bloat - a restart cleans up that
> memory use somewhat. When I do that I expect all my history for each tab to
> be retained, and to be able to undo closed tabs.
History would be retained, old form data would be cleared, closed tabs would be
forgotten
Tobias Besemer wrote:
> Am Donnerstag, 26. Juni 2014 17:33:22 UTC+2 schrieb Tobias Besemer:
> OK, I was redirected in bug 810932 to this group for discussions about how to
> change/improve the sessionstore ...
Thanks for moving the discussion here.
> ... so I now want to start the discussion wit
I should point out that after a restart my FF memory usage went down 150,000K
while the session store size remained the same.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
If this behavior were changed I'd change it back locally with a pref
or addon or something. I can't think of a scenario where I want
firefox to intentionally forget state for me, let alone on process
exit. There are lots of reasons to exit (powering off to install
windows updates, restarting FF to
> ... so I now want to start the discussion with my idea, that ss.js should
> forget the most things when Firefox gets closed manual by the user,
> originally posted here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=810932#c22
>
> So what do others / the developers think about this ???
I dis
Am Donnerstag, 26. Juni 2014 17:33:22 UTC+2 schrieb Tobias Besemer:
> A new topic to move the discussions from the bugs to this group.
>
>
>
> Bug 669034 - (sessionRestoreJank) [meta] Re-architect session restore to
> avoid periodic freezes
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=6690
A new topic to move the discussions from the bugs to this group.
Bug 669034 - (sessionRestoreJank) [meta] Re-architect session restore to avoid
periodic freezes
https://bugzilla.mozilla.org/show_bug.cgi?id=669034
Bug 810932 - Investigate how to redesign sessionstore.js for improved
performance
36 matches
Mail list logo
