News Forum Phone database

> New Topic
> Reply
< Esato Forum Index > Sony Ericsson / Sony > Symbian phones > Demand Paging for UIQ3 would you want it now? Bookmark topic

I'm sick of all this "SE is a small company compared to Nokia" and "SE don't have the resources" blurb.

If they want to compete with Nokia and others they have to beef up their business to suit.

This is just another perfect example of SE falling over compared to the competition and why it is possibly better to buy Nokia as the device WILL be supported once it's not available any more or been replaced with an update.

The P990 is a good enough phone (apart from some bugs) and demand paging would be a massive improvement. It's just not going to happen given SE's current regime of poor customer support and not focusing on non-current devices. They need to get better programmers who actually know the hardware, the product, the competition and more importantly what the customers want!
--
Posted: 2007-12-09 01:24:19
Edit : Quote


@Nipsen:

Like I say, the demand paging mechanism must allows for customisation of how it is used. I dont think it is "one-size-fit-all". Programmers can optimise the libraries by specifying group of pages as wired set. Your scenario where constant page faults can be minimised. Even if there are constant page faults the OS can slot these in during low cpu cycle (e.g. when user is entering inputs etc) without compromising performance.

btw: I dont think a 0.5Mb program will use demand paging. We know big prog like gallery, map, web browser do.

Like makbil/dogmann have said, a phone limitation is RAM and battery. Any mechanism that save these certainly is desirable. And desirable results are what we have seen in N95 v20 firmware. But all the negativity that you mentioned have not shown its ugly head. As of now your argument is not tenable.


--
Posted: 2007-12-09 04:30:19
Edit : Quote


BTW, there aren't many programs around 0.5MB on UIQ 3 devices.

Calendar - 0.8 MB
Contacts - 0.7 MB
Music Player - 2.0 MB
Xplore - 1.6 MB
Picture Gallery - 1.0 MB
Camera - 1.3 MB
Mobireader - 3.1 MB
Web - 3.1 MB (as we know this can get larger)

and my all-time personal favourite...
Messaging - 3.9 MB (which means many P990 users actually can't leave it running in the background on a daily basis, as it'll constantly be closed down by the system once other apps are opened)



[ This Message was edited by: aqualung on 2007-12-09 04:59 ]
--
Posted: 2007-12-09 05:50:53
Edit : Quote


Nipsen... sound like you think the old batch of UIQ phones are beyond repair lol...

well they should at least jam it in the p1i and w960... leave the p990 to rot...

buggy software aside.. if the use of demand paging can increase the ram availability of the n95 it would most definitely help the non existing ram in the p990 lol
--
Posted: 2007-12-09 06:06:49
Edit : Quote


Let's not forget that demand paging should be a core system function if implemented. As such, fortunately it is not up to SE but rather to Symbian to implement this.
Now, can you imagine SE getting its act together to adapt a new Symbian OS for P990? It took them 3 years to get the P990 to its current condition, do you think they will spend a single minute on a product they have already declared obsolete?
--
Posted: 2007-12-09 12:15:03
Edit : Quote


@aqualung
Actually, with the usage Opera 8.65 takes about 6 - 6.5 MB. I checked it many times.
--
Posted: 2007-12-09 12:34:24
Edit : Quote



No, but if I wanted something to be done, I wouldn't pin my hopes on, or agitate for, something that won't work.

Let's take an example - how much extra working ram would be saved on the picture gallery with demand paging? What the lot of you seem to be suggesting, is that because of demand paging, the ram- print must always be smaller. But what uses ram is not the repeated functions that generates the thumbnails, for example. Those objects are the one- shot resources that are read into ram, and then disposed of later. The code- function used will simply be loaded at the beginning. And this would happen without demand paging as well. So when you're demanding demand paging here, what we're really talking about is this: that the program is loaded, and, say, the thumbnail- functions that are used several times, will be loaded only when it's used the first time. Which would be about at startup. The pictures and so on that use the vastly biggest amounts of ram, will still be exactly the same.

So again - how much ram is going to be saved? (Keep in mind that the "used" ram, includes ram that the program allocates for reading images, etc).

The same goes for opera - how many separate instances that take ram do you think are loaded without being used? Or otherwise not loaded at the point they are used, and then disposed of when the page or the instance is closed again? And, loading pictures and text will take working ram anyway. That's not going to change.

Similarly -in the messenger- program - how long do you think it would take to load: the email- account manager, the input window, and so on? One run? Two? What if you run the program all day? How much would you save from that? Not to mention that most of the resources are loaded on demand, and would not be automatically disposed of with the use of demand paging.


This just all illustrates the point I made very early on: that unless you have separate functions in the same program that often use the same codebase, and so duplicate loading the resources (we can already dismiss any benefit from recycling code /between programs/ in demand paging because there is no virtual memory, of course) - the only benefit you'll get is decreased startup- use of ram, at the cost of increased response- time. And then the ram- use will grow to exactly the same or bigger size as before, if you actually use the program. Also, the saved resources on load- time for creating objects can be dismissed.

In other words, until we get bigger libraries for graphics, for example, that have some functions used often that would have aspects not necessarily rendered. Or can use connectivity- libraries over several different components at the same time (which at the moment is solved by asking the OS for a running service) - what in the world is the point, other than getting yourself a smaller number on the stat- screen at startup?

Or is the cosmetics so important that whether it actually helps doesn't matter?

Not to mention (which I actually did, I think) that the same effect of lesser startup ram could be achieved by simply splitting the functions in the OS into separate programs, and then ask those programs for the services, instead of the already running OS package. Which, strangely enough, is what UIQ has done with things like activesync and the vpn- client.

But no - don't want to hear that. Honestly, can't you bash SE for something they actually did screw up? There's literally hundreds of f**k- ups, from program- support to design and market and company philosophy to just plain fraud with the w vs k series - and there is serious room for improvement on the p990 and the m600 if they just mobilised and split the development of the firmware from the other UIQ devices (and optimised the often used programs for use with little ram. It might cut the battery time, but it would give you what you want. Perfectly possible).

So why in the world are you going for a drop on the demand paging, of all possible things? It's just like... people have been sniffing MacWorld again, or have taken the last nokia- presentation as gospel truth, as usual. But hey - it's can't be that, now can it. No(!) - believe in demand paging! And it will, lo' and behold, be something to clamour on about for yonks, while discrediting any concern "the customers" might've had in the first place.

But hey, now that I think about it - who am I to complain? I don't own a nice p990. And hey, I think it's a doomed unit that sucks donkey- balls, so why should I care
--
Posted: 2007-12-09 13:53:36
Edit : Quote


@Nipsen

Thanks for the diatribe

Apart from the snippy little comment at the end, quite an entertaining read.

As I said earlier, all of this speculation is just that....theorising. Mostly because we're pretty damn sure SE won't be making the remotest effort to implement this.

And if they did, chances are it'll be a half-hearted effort, buggy and unusable.

I think we're all aware of where SE's shortcomings are.....once Mr K has finished with his whistle-stop tour of all the SE offices worldwide (!) we might even get an answer to our open letter.

For those of us who were lucky enough to get a P990 of good build quality, the P990's only major shortfalling is the RAM. Stability-wise the latest FW is solid.
Obviously some can work around the RAM limitations, others can't.


--
Posted: 2007-12-09 14:51:51
Edit : Quote


@Nipsen, let's not forget that most programs use system APIs, therefore there can be a lot of common code between programs. While the very specific picture library example you have given may not benefit much from demand paging, other applications with a larger footprint, such as messaging and Worldmate Pro, may benefit hugely from this.
I see this as a purely academic discussion, neither the P990, M600 or the P1 or any other present UIQ3 devices will get this. If dynamic garbage collection is implemented in Symbian 9.5 and SE uses that, this will be as close as we can get to a decent memory management on an SE smartphone.
--
Posted: 2007-12-09 14:56:40
Edit : Quote


Yes. I understand that. But you do see that individual programs won't benefit "hugely" from a demand paging model that doesn't involve recycling between programs? And which will typically use all the modules in a single run? As well as that we're not talking about temporarily loaded resources?

And don't give me "it's just academic", when you're using an abstract theoretical scenario that doesn't necessarily apply, in order to say: "that will obviously mean /this particular program/ on /this particular platform/ with /these particular aims for energy consumption/ will benefit massively". That's the entire point: this kind of abstraction is too easy, and it doesn't tell us anything useful - because we haven't described where and in what conditions the program is supposed to work in.

...
--
Posted: 2007-12-09 15:16:19
Edit : Quote

---

New Topic   Reply

Forum Index