Please create an account to participate in the Slashdot moderation system


Forgot your password?
Software Ubuntu Windows News Technology

The Insidious Creep of Latency Hell 297

Twinbee writes "Gamers often find 'input lag' annoying, but over the years, delay has crept into many other gadgets with equally painful results. Something as simple as mobile communication or changing TV channels can suffer. Software too is far from innocent (Java or Visual Studio 2010 anyone?), and even the desktop itself is riddled with 'invisible' latencies which can frustrate users (take the new Launcher bar in Ubuntu 11 for example). More worryingly, Bufferbloat is a problem that plagues the internet, but has only recently hit the news. Half of the problem is that it's often difficult to pin down unless you look out for it. As Mick West pointed out: 'Players, and sometimes even designers, cannot always put into words what they feel is wrong with a particular game's controls ... Or they might not be able to tell you anything, and simply say the game sucked, without really understanding why it sucked.'"
This discussion has been archived. No new comments can be posted.

The Insidious Creep of Latency Hell

Comments Filter:
  • I thought things were supposed to get faster with newer technology but it does indeed look like the newer devices run slower becuase of bloated apps and firmware. Maybe this has to do with programming being "bestshored" =D nowadays.

  • Changing TV channels (Score:5, Interesting)

    by Anonymous Coward on Tuesday May 03, 2011 @05:36PM (#36016748)

    And here I thoguht I was the only one complaining that changing channels gets slower and slower with every new receiver box.
    On analog it was basically instant, less than 100ms.
    First digital box took half a second. Full HD box sometimes takes a whole second or more (and it's not even deterministic anymore)

    That SUCKS big time!

    • by Dr_Barnowl ( 709838 ) on Tuesday May 03, 2011 @05:38PM (#36016778)

      That's down to compressed stream buffering. An analog box could be instant because every frame was transmitted uncompressed. With digital TV, you have to wait for a keyframe at least.

      • by JordanL ( 886154 )
        This does not explain the > 500ms delay when trying to use the guide.
        • by Luyseyal ( 3154 )

          It might if it's getting the channel's feed in the background. It is annoying though. They really ought to consider a "just the listings, I don't want to see the channel at the same time" option. That would be a TON faster.


        • by El_Isma ( 979791 )

          That's due to how digital cable works. I'll speak of DVB since that's what I know (I don't know what USA is using, but surely it will be similar). DVB sends a big stream composed of several smaller streams, some of those are video/audio streams, some are channel information (the guide, the streams IDs (audio/video/cc) of the channel, etc), others are info on the stream itself (carrier frequencies) or general information (time).

          For the video stream, as the parent poster said, you'll have to wait to get a key

        • TV Guide is instant on over-the-air television. Mainly because the data is immediately available from the box's memory. Anything past 3 hours takes a little longer to fill-in, since those are only sent every 5 seconds. Past 1 day, the data is only sent every 30 seconds.

          As for channel changing, I've noticed some boxes are slow as snails, while others are instant and display the picture almost as fast as analog. It all depends on the manufacturer.

        • This does not explain the > 500ms delay when trying to use the guide.

          That's probably due to being 'keyframe' compression. The way that works is you start with frame 0, and that is the entire picture. The computer looks at frame 1, compares it to frame 0, and determines the difference. Frame 1 is now a partial frame that is overlaid on top of frame 0. Then frame 2 repeats the process, you end up with a partial frame which looks a lot like an old cel of animation missing its background, yadda yadda yadda. Then, when you reach a certain threshold (like 96 frames, maybe?) a

        • by JonySuede ( 1908576 ) on Tuesday May 03, 2011 @07:26PM (#36018084) Journal

          it is the encryption technique utilized that introduce this lag. There is a key change at about 1s so it must wait until the next key to decode the stream.

        • by jo7hs2 ( 884069 )
          Well, at least for those of us stuck with Comcast, I suppose the advertising crammed into the guide might play a role.
      • by Omnifarious ( 11933 ) * <> on Tuesday May 03, 2011 @06:15PM (#36017208) Homepage Journal

        Since many of these technologies transmit the data for all channels simultaneously, why not just scan for key frames and store the last key frame received for each channel? It might be that even just scanning for key frames might be too CPU intensive to do for all channels. But most people, when channel flipping, do so in a fairly predictable order. You could start doing this for the most likely targets for channel flipping when channel flipping behavior is detected.

        • A cable box needs to have a separate tuner for each stream. Live TV takes one, each recording show takes one, etc. and such keyframe prefetching would also take at least one. Most cable boxes only have 2-3 tuners, and inevitably they're all going to be taken. So while this could definitely hide the latency in some situations, it's not a perfect solution.

          Cable companies are also beginning to use SDV, which broadcasts channels on demand instead of all at once. Some latency will be involved here too, becau

          • I the case of a request things get a little easier. The entity serving up the response can do a little extra work to send an immediate key frame and tailor the rest of the stream up until the next key frame for the requestor before shifting them to just getting a duplicate of the data everybody else is getting. You still have the request latency, but I bet you could still manage to keep the latency under 50ms if you tried hard.

          • by tibit ( 1762298 )

            A cable box needs one wideband tuner and an SDR that can demodulate all the channels at once. There's obviously no need to do video decoding (decompression), just buffering of some subset of channels (say most often recently used). One QAM channel brings about 34.5 Mbit/s. A modern ASIC should have no problem easily dealing with demodulating and buffering twenty such channels (700 Mbit/s) when presented with a wideband IF output. The buffering only needs 90 Mbytes/s for 20 channels. That's not much if you

        • Since many of these technologies transmit the data for all channels simultaneously, why not just scan for key frames and store the last key frame received for each channel?

          Only a few HD channels are transmitted on each 6 MHz carrier. Scanning for keyframes on other carriers would need multiple tuners, which increases the cost of the cable box.

        • I'm guessing Microsoft does something like for their IPTV platform (used in U-Verse in the US). You receive a unicast stream until the multicast stream is joined (and presumably another keyframe reached). Although this isn't always seamless and you can't rewind to what you received in the unicast stream.

        • by scrib ( 1277042 )

          Saving the last key frame is also a waste, unless you save all the deltas up to the current time, too. That's the same as trying to play all the channels at once.

          You wait for the key frame, display it, and start viewing the stream from there. Using an old key frame and viewing the deltas somewhere midstream would result in weird looking corruption until the next key frame was displayed. Best just to wait.

          • In my opinion, showing just a still keyframe, or a keyframe with weird corruption is still preferable to channel switching taking a full 500-2000ms. Though the weird corruption would probably be a customer education issue.

      • No, in my case I can trace the worst of it directly the the Time Warner Cable channel guide. Slowly rolled out in Austin over a few days, I immediately noticed a huge delay when changing channels, and was able to confirm with friends and neighbors across the city (some who had HD boxes, some not, some with the new guide, some without), that those who had the new channel guide were noticeably slowed (~1s), and those with the old guide didn't see anything unusual... until they too received the "upgrade".

        The t

    • This is just anecdotal, and probably a one-off kind of thing, but the other day my Comcast cable box/DVR was being very slow to do anything (i.e. press a button on the remote, wait several seconds for a response). I fixed it by unplugging it and plugging it back in again.

      So, I guess what I'm saying is: have you tried rebooting it? :P
    • by rsborg ( 111459 )

      And here I thoguht I was the only one complaining that changing channels gets slower and slower with every new receiver box.
      On analog it was basically instant, less than 100ms.
      First digital box took half a second. Full HD box sometimes takes a whole second or more (and it's not even deterministic anymore)

      That SUCKS big time!

      Or a more positive spin,maybe this will result in less TV watched. I've noticed that since we have gone Dish (wife must have TV5Monde), we hardly watch TV at all (the little tot watches the most, probably 30m-1hr a day avg, but this is all netflix streaming/DVR/appletv content).

      If some startup or established company is keen on solving this, they could be highly disruptive in the TV space.

    • by TapeCutter ( 624760 ) on Tuesday May 03, 2011 @07:04PM (#36017768) Journal
      When I was a kid I had to wait for the B&W TV to warm up, now I'm an old fart I have to wait just as long for the digital set top box to boot up. Somewhere in between I had a TV that came on instantly.
      • Ha, I remember that. On a lot of sets a tiny dot of light would appear in the middle of the screen, then after about five seconds or so the dot would inflate to fill the screen. There was hardly ever anything on back then, too...
  • N900 (Score:5, Interesting)

    by Dr_Barnowl ( 709838 ) on Tuesday May 03, 2011 @05:37PM (#36016762)

    The N900 suffers from this, alas.

    I can't comprehend why the phone app isn't in memory on boot. It's a PHONE. Instead, when the phone rings you have to wait several seconds for the phone application to load.

    In contrast, my wife's new HTC Z snaps and zings along with Android, even though it's "bloaty" Java / Davlik.

    • by blair1q ( 305137 )

      Is it a phone?

      I use my "phone" for phoning and receiving phone calls and talking on the phone maybe...I dunno, 0.6% of the time it's lit up?

      It's a computer. If I happened to put a phone in there, then that saves me having also to have a phone.

      Though I will get a burner if I think Jack Bauer is on to me. Maybe a six-pack. I ain't stupid.

      • by maxume ( 22995 )

        That's a hell of an argument, it's not a phone, it is just a shitty computer with some cellular and audio hardware built in.

        But at least they made a computer with a shitty phone application, and not a just a shitty phone.

    • Re:N900 (Score:4, Informative)

      by Microlith ( 54737 ) on Tuesday May 03, 2011 @05:50PM (#36016958)

      I can't comprehend why the phone app isn't in memory on boot. It's a PHONE.

      As Nokia put it, it's a device designed around "mobile computing." The phone app is entirely secondary (unlike on most Symbian devices, which have physical buttons) and is mostly there as a convenience thing. The primary reason the circuitry for it is even there is for 3G data.

      Instead, when the phone rings you have to wait several seconds for the phone application to load.

      Which lies totally outside my experience, where it comes up instantly.

      90% of the lag on the N900 is if you've just done something memory intensive (notably the browser) that caused stuff to be paged out to the eMMC, which isn't exactly fast. But the crippling problems that used to cause were resolved back in September or so with the PR1.3 update.

      In contrast, my wife's new HTC Z snaps and zings along with Android, even though it's "bloaty" Java / Davlik.

      That's because it's a phone, and not a more general purpose sort of device. In fact, they don't even want you messing with it which is why you have to root the damned thing.

      • What do you mean about the messaging? My Dell Streak has been used a lot more for texting, web browsing , ebook reading and youtube than it has as a phone. Likewise my Xoom doesn't even have anything but wifi.. Android is no more a phone OS than iOS is.

        • What do you mean about the messaging?

          messing, not messaging. Regardless, they don't want you stepping outside the carefully set bounds of the Android OS and they try to enforce it by making you root the system.

          The N900, by contrast, is a much more typical Linux system that you can freely enable root access via official methods. Tuning has definitely been needed, but my point against the GP was that I had not seen the latency he talks about in response to phone calls, and why the phone application wasn't loa

      • by lewiscr ( 3314 )
        The HTC's aren't phones either. Nothing running Linux qualifies as "just a phone". This includes most "dumb" flip phones (which are running embedded linux, QNX, or some other embedded OS). The real time OSes usually handle it better, but I've had those sort of problems with them too. I don't remember the last time I had a cell phone that didn't have any applications (even if it was a manufacturer installed MP3 player app).
  • by RichardJenkins ( 1362463 ) on Tuesday May 03, 2011 @05:38PM (#36016776)

    Whenever I use iReport there is about a sixth of a second delay between interacting with it and it doing what I asked. It's barely noticeable but still drives me insane.

  • RTFA (Score:5, Funny)

    by Dog-Cow ( 21281 ) on Tuesday May 03, 2011 @05:39PM (#36016798)

    I was going to read the article, but it took too long to load.

  • by omnichad ( 1198475 ) on Tuesday May 03, 2011 @05:40PM (#36016806) Homepage

    I don't personally have Satellite, but it seems that almost every satellite receiver is underpowered to run the GUI.

    • by gknoy ( 899301 )

      I've had a slightly different experience. I use DirecTV; while it's not the snappiest at changing channels, the channel listing menu is fairly responsive. In comparison, using my in-laws' (or my dad's) digital cable is like trying to use the application through a VPN into a slow windows ME box in Elbonia. Not only was it slow to change channels, the channel list itself had noticeable rendering latency and artifacts.

    • At least then you get the product slightly cheaper. I find products with plenty of cpu far more annoying. Take the Xbox 360 UI. A lot of the menu navigation has a delay of about 1 sec, just for doing some animation. And input is disabled in that time.

  • slashdot (Score:5, Insightful)

    by Anonymous Coward on Tuesday May 03, 2011 @05:41PM (#36016832)

    Slashdot's Javascript.

    • by nu1x ( 992092 ) on Tuesday May 03, 2011 @05:48PM (#36016910)

      It actually drives me insane, it is markedly worse, I read less stories because of it (because I do not like the feel of the site so much).

      I would bet most of the actual slashdot users feel (think ?) the same way. Why is there no mass appeal to change it back / forward in a more reasonable (i.e., simpler) direction ?

      • by Culture20 ( 968837 ) on Tuesday May 03, 2011 @06:38PM (#36017460)
        I turned it off and went with the old style. I'll take a 5 minute wait between posts any day before trying to
        And yes, the posts lower in the chain would often look like that with the most recent javascript fiasco. I have no idea whether it's still that ugly.
      • by Teckla ( 630646 )

        It actually drives me insane, it is markedly worse, I read less stories because of it (because I do not like the feel of the site so much).

        The "Many more" button (to get more stories) has never worked for me. This is across multiple computers and operating systems. I read less Slashdot because I simply can't easily get to the older stories.

        I'm sure it has something to do with my account setup, but -- bah. The new Slashdot is a train wreck.

        • by Evtim ( 1022085 )

          Strange! /. always worked for me smooth as silk except very long threads can take some time to open. I am a lame Windows user and it worked just fine with XP+Firefox and now 7+Firefox.

          BUT, on the phone (HTC desire) - tragedy!! Stock browser does not scale the text properly. Opera mini scales OK, but refuses to display more than the 250 comments. Nothing helps - open in new tab, open in new window, the same window - it just does not work. View more stories sometimes works sometimes not but never works from t

          • by Teckla ( 630646 )

            Strange! /. always worked for me smooth as silk except very long threads can take some time to open. I am a lame Windows user and it worked just fine with XP+Firefox and now 7+Firefox.

            My computer is a single core 1.66 GHz Atom, so I'm somewhat used to things being kind of slow, but Slashdot takes the cake. (Running Windows 7)

            I am not very good with computers and programming - am I missing something?

            I don't think you're missing anything. The new Slashdot is just poorly written.

    • ^^ this

      Any popular story, such as the recent Bin Laden killing story, opens SSLLOOWWLLYY... It takes maybe 2-3 minutes to open, and during that time, the browser is unresponsive. (I have a single core HT laptop with 3 gigs of ram). Once the page loads, actually scrolling is a joke. The lag there is in the 5-10 second range. C'mon /.
      • Use firefox instead of chrome. ;-) Works like a charm for me and I don't have your specs.

        • I use IE7... It's a work laptop. My computer at home runs much better (FF on dual core AMD X2 with 4 gigs), but still I would expect better performance on IE7. I'm sure that I am not the only one using it on this site.
    • by Hatta ( 162192 )

      Then block it. I use NoScript. Set your discussion preferences to "Classic Discussion System (D1)" for best effect.

  • I miss the days where manually compensating for lag in games like Quake was unquestionable and accepted as a part of the multiplayer gaming experience. It's hard to imagine trying to cope with such a thing these days.
  • Linus Torvalds has rejected patch after patch after patch that would make Linux into BeOS style latency. He has rejected them all. Why?

    because he wants to goose the server performance numbers. thats basically the story of the last 20 years of linux.

    • by Twinbee ( 767046 )

      Hi, I wrote the article in the story.

      Can you give me some verification and links to your comment, and I might see if I can fit it into the article. As you say, there should always be a sensible balance between latency and throughput.

  • by MetalliQaZ ( 539913 ) on Tuesday May 03, 2011 @05:48PM (#36016924)

    I have definitely noticed addition latency in the UI with VS2010, and it has always bugged me. I can't be certain if it is VS itself or if the underlying WPF is to blame. My current belief, and I have no facts to back this up, is that the VS UI is simply much more complicated than the "typical" use case that was targeted for WPF, and as a result, low-to-mid range computers fail to meet a human's expectations of UI latency.

    On a separate beef, why is it that so many people put up with the AWFUL latency on smartphones? Especially when browsing the web, it can sometimes become unusable. The phones get more and more powerful, but instead of making the last UI work, the designers just add more and more flashy crap instead. UI is just as slow but it looks cool in the ads.
    When I don't have a real computer nearby, I can use the android browser when I need to, because I recognize the flaws and can patiently work around them. It kills me to watch my girlfriend attempt to navigate the interface of her nook color. Usually goes something like this...
    1. press UI element
    2. no response, press harder (because that's what humans do when a button doesn't work)
    3. harder has no effect, start tapping repeatedly
    4. UI finally changes, menu pops up and immediately goes away, having tapped on an unknown selection.
    5. human gets mad, claims unit is broken, goes to check email on 5 year old PC.

    As an added bonus, the PC doesn't require you to put your fingers in the way of what you're trying to look at.


    • How much of that is connection lag and how much is UI though? The connection is understandable, depending on signal strength and other variables. UI lag is not. If its lag in the browser its probably connection related.
      • by tepples ( 727027 )

        How much of that is connection lag and how much is UI though?

        If touching doesn't immediately produce a visual or audio response that the device is trying to load something over the connection, then it's perceived as UI lag. That's part of why Slashdot has that little "Working" box with a throbber that pops up at the bottom of the screen when I preview a comment.

    • by umghhh ( 965931 )
      I hardly ever watch the TV (most of it is crap anyway and if I watch then I chose in advance and do not flip between channels). The phone I use has indeed lags sometimes but this has less to do with the languages or frameworks used but a lot with processors and batteries not being able to cope - not sure if they all still do it but they actually inserted slower processors into smart phones on purpose so that the battery lasts longer. Still I use my phone as a calendar, alarm clock and pin generator for my
      • by tepples ( 727027 )

        The phone I use has indeed lags sometimes but this has less to do with the languages or frameworks used but a lot with processors and batteries not being able to cope

        My Super NES with a 3.6 MHz 65C816 CPU doesn't lag when I play Super NES games. So why should a phone with a CPU 1000 times faster lag?

    • by cnettel ( 836611 )
      I don't know why, but my impression has been that the UI is actually more responsive in VS 2010 compared to 2008. My personal pet theory has been that GDI+ back-buffering can get slow on very high resolutions (2560 * 1600), while WPF would stack up better. That wouldn't conflict with your theory, though, just that there is some point where VS2010 will overtake 2008 when you have enough graphics power and enough pixels to blit.
  • Slashdot (Score:5, Insightful)

    by Bobfrankly1 ( 1043848 ) on Tuesday May 03, 2011 @05:49PM (#36016950)
    I had an incredibly insightful comment, but I forgot it while waiting 2ms for the comment interface to load. I remembered and forgot it again during the 10 seconds it took the preview to render.
    • by tepples ( 727027 )
      The 10-second preview wait is to port scan your IPv4 address for open proxies. I compose long replies in Gedit or Notepad while I wait for Slashdot to catch up.
  • by rickb928 ( 945187 ) on Tuesday May 03, 2011 @05:52PM (#36016984) Homepage Journal

    I read about this right here in January []. And February [].

    Seriously, how many times can you recycle the same story with slightly (and I mean slightly) different nuances, but the same frakking story?

    Next thing you know, I'll be reading another story on this with the angle 'women and children affected the most []'.

    Slashdot is becoming the USA Today of the Internet. Isn't it time for another site upgrade?

  • If you don't know what those are, or how to use them, or they're just not available on your platform of choice, then you're part of the problem.
  • by MobyDisk ( 75490 ) on Tuesday May 03, 2011 @06:11PM (#36017170) Homepage

    The first article in the summary has some silly ideas on how to fix this:

    What can we do reverse the onslaught of latency in all its forms? ... First off, we can make LCD (or future OLED/QLED) monitors run at 120 or even 240 frames per second.

    What?!?! 1) That is not possible and 2) That would not help. There are so many reasons for this I can't even list them all.

    First, there isn't an LCD panel in existence that actually responds that fast. Those phony 240 hz screens don't actually change the pixels 240 times per second. We don't need faster displays to solve a software problem.

    If the software provided a 1/60 second delay, that would be just fine. The issue is that we are not taking advantage of the refresh rates we have no - so increasing those rates doesn't help. Heck -- that's probably faster than the debouncing circuits in the controller!

    Compensating for a longer pipeline by increasing clock speed doesn't help anyway, because to get the higher rate you need to increase the pipeline more...

    • Those phony 240 hz screens don't actually change the pixels 240 times per second.

      Well your retina doesn't react instantaneously either, but your brain knows how to compensate for it. My personal theory is that the slow response of the LCD is also an analog or analog-appearing process and your brain will find it less offensive than other types of timing distortions.

      But even if the LCD itself doesn't respond instantaneously, increasing the frame rate can potentially decrease every frame-count-denominated so

    • by AdamHaun ( 43173 )

      I think he's talking about the image processing. LCD controllers need to see multiple frames in advance so they can set the control signals right to minimize ghosting. This "response time" is a marketing number, so they try to make it as small as possible. Unfortunately, that means delaying one or more input frames plus some extra processing time. At 60Hz, one frame is 16ms, which is a large unit for input lag purposes. Changing to 120Hz means the next frame comes faster, which in theory means less lag.


    • by epyT-R ( 613989 )

      going from 60hz to 120hz on my crt helped latency considerably. however, I"m one of those old school quake heads who sees stuff like that. today's world of laggy GUIs and clunky virtualized binaries (java/.net et al) drives me insane...especially since the cpus we have today are roughly 10x faster than they were in 1998.

  • I cover how to measure buffer bloat, recreate the problem (trivially easy, in my case a single high speed upload saturates my 3 megabit uplink and ping times go from 50-60ms to 1000+ms. []
    • by geekoid ( 135745 )

      Unless some one can give me a 'do that and you will see it' test that works I remain skeptical that buffer bloat is the cause.

      Its sounds more like confirmation bias tied with a different issue.

      If someone running a twitch game(Usually TF2), download bit torrent(WoW patch or ISO), on a computer (AMD Quade, 4 Gigs)that's may also be serving up media to my TV(10/100/1000) can't experience this, does it really exist?

      I have 25/20 Mbps

  • by formfeed ( 703859 ) on Tuesday May 03, 2011 @06:41PM (#36017506)

    Sometimes in a thunderstorm you see lightning, but it can take several seconds till you hear thunder.

    Pretty bad design, imho.

  • Really (Score:5, Informative)

    by geekoid ( 135745 ) <dadinportland&yahoo,com> on Tuesday May 03, 2011 @07:03PM (#36017744) Homepage Journal

    "(Java or Visual Studio 2010 anyone?"
    Really? do you even know what the hell you are talking about? OR did these two think pop into your skull and you use your meaty finger to pound out some sort of text in a vain effort to stay relevant?

    Java or Visual Studio 2010 anyone?
    Crappy programmers.

    And has anyone documented a repeatable real world test for 'bufferbloat' or is this still an academic issue?

  • by MaWeiTao ( 908546 ) on Tuesday May 03, 2011 @07:16PM (#36017936)

    This is one of the reasons why on all the devices and computers I use I disable animations when I'm permitted.

    I think the real problem, however, is that we've grown increasingly impatient. I notice it in myself. Some application takes over 3 seconds to open and I start getting agitated, wondering what the hell is taking so long.

    Think back to the earlier days of computing when it might take 30 seconds or more to get an application started. I recall on my PCjr booting up games and sitting there for a good minute while the drive ground away. That said, some games nowadays have some rather appalling load times. But look at what has to be loaded compared to those games from the 80s.

    I also recall trying to play games that were more demanding than my computer could handle. I'd hit a key and get an action a fraction of a second later. I got used to it, but it's something that would be intolerable today.

    Even using early versions of Windows and Mac OS was an exercise in patience, especially if something was going on in the background. And what about waiting for a simple website to load, especially over 56kbps? Hell, what about loading up text-only menus on your favorite BBS via 2400 baud?

    The simple fact is that we've been spoiled and as such have grown increasingly impatient over shrinking timescales. That said, given all the computing power at the tips of my fingers I do expect everything to be instant.

    • by shish ( 588640 )

      Think back to the earlier days of computing when it might take 30 seconds or more to get an application started

      Back when I wrote one of my first gui programs, I added sleep() calls into the load process, because otherwise the splash screen disappeared before you saw the progress bar move and that wasn't so "cool"...

    • by epyT-R ( 613989 )

      we aren't spoiled. we're more dependent. in the 80s you used your computer to play simplistic video games and maybe type a one page school assignment.. if you were learning programming, you were coding simple routines in assembly, maybe C if you were lucky enough to have a 68000 based machine with sufficient ram to run a full suite of tools..even then you were still coding a lot of assembly.

      Today, programmers are pumping out bloated binaries using point-and-stick development environments. this problem is ad

  • .....I want to say it was around 2003 or so around here, when there were all sorts of discussions about "the cost of hardware and bandwidth is so cheap now, we don't need to optimize for the machine, we should instead optimize for the programmer". This came up again and again, and all the n00b programmers danced around their shiny Powermacs and sang and held hands and ratified it.

    Notice how everything has exploded exponentially in size, and each revision of any bit of software has been noticeably more slug

  • One key example I can come up with was the external folding keyboard for the Dell Axim X5 I bought as an "upgrade" from a Handspring Visor I was using for note taking in undergrad. The input delay was so bad that you could type several paragraphs before they would appear in the device. Totally destroyed the device for me, and I ended up going back to paper, as the Handspring was no longer in my possession. Not to focus on Dell, but my Inspiron 8000 had a similar problem, too. I got it as a desktop replacem
  • by tibit ( 1762298 ) on Wednesday May 04, 2011 @01:09AM (#36020622)

    The latency problem in non-networked applications is ultimately caused by poor software engineering, starting with system-provided APIs. Most of "bog standard" system libraries were designed for something entirely different than what they end up used for. The "normal" C I/O paradigm is used everywhere, yet it was really designed for batch applications, not for interactive use. The only way to do almost any filesystem and network interaction should be to submit a request, then react when the results come back, all the while being receptive to other "results" (events) coming in. Unfortunately, designing things this way requires a certain discipline and a mindset, and default APIs and "industry practices" simply don't encourage it at all.

    A correctly engineered system API should not have any blocking calls apart from the "wait for events" call, it's as simple as that. It's very rare that an application is only waiting for one thing to happen. Even something as simple as a UNIX cat has two file descriptors open, and simultaneously waits for stuff to come and and for stuff to finish going out, with a buffer in-between (I'm ignoring no-copy APIs for a moment). Coding it up as a read followed by a write is, at best, wishful thinking. Of course event-based programming is something that seems like a lot of extra work, but it's just a matter of getting used to doing things the right way.

    In fact, if you decide to code up your whole system in an entirely reactive way, you gain other benefits. By reactive I mean you could reduce every application thread's interface to a single processEvent(event), run-to-completion function that you implement. As it turns out, it becomes almost natural to get the guts of the processEvent() function implemented as a state machine. The state machine formalism often helps in producing better quality code, and it certainly makes it very easy to trace interaction with the outside world. Miro Samek shows a striking example []: the supposedly "so simple it couldn't possibly go wrong" calculator example from old Visual Basic has several bugs that stem from its bug-prone yet commonplace design. The calculator's state is spread out in an ad-hoc manner in various variables, and the tests done on those variables in response to external UI events pretty much amount to a buggy reconstruction of a single state variable to drive a state machine.

    The state machine paradigm is in somewhat stark contrast to the way a typical GUI application is designed, where you have on_fooBar methods that get invoked when fooBar event happens. In the fooBar method it's up to you to verify that the application is in the correct state to do whatever fooBar calls for. This requires forethought, and status quo indicates that it's easy to get it wrong. Perhaps that's the reason: the de-facto mode of implementing reactions to external events is so broken that it's not used for much besides the GUI. Perhaps this is why "quick" system calls are usually done in line and end up blocking the whole application, or at least one thread, and those are not free either so why waste them with blocking APIs?! Apart from perhaps querying the current time or current username, there are really no "quick" system calls. Simple things like listing a directory or getting a key's value from the registry can potentially take seconds if your drive is thrashing around due to high I/O demand, or if the network happens to be slow.

    Of course the line has to be drawn somewhere, so let's assume that paging of code, libraries and heap is something we should not worry about because it cannot be helped much. At that point one realizes that indiscriminate memmapping of data files can be problematic in itself: a memory-mapped file is, after all, supposed to hide the fact that you are doing a request-response that can be either very fast or very, very slow. The latter is something you should explicitly handle, and with memmap it's at best cumbersome: you have to use some API to check if given page is av

"We don't care. We don't have to. We're the Phone Company."