Hacker News Reader

Comment by ClayFerguson | Hacker News Reader

Doing GUI calls is a notorious way to slow down apps. I sped up an app (major software from major large corporation) by a factor of 10x a few years back by removing GUI updates. What you have to do is create a thread that refreshes the GUI periodically and not let your main worker thread ever work on the GUI. This particular app was an Eclipse Plugin (a source control app) and the Eclipse SWT to update the console log window was being called after every file operation (of which there were 10s of thousands). All I did was move the GUI refreshing into it's own thread, and call it only every 250millis or so. I was hailed a hero, and deservedly so, for speeding up our app by 10X and was one of my most satisfying accomplishments in my software career.

View on HN

This strategy is also encouraged by best iOS development practices (main thread never works on GUI).

Edit: 'main' as in the one doing the one doing the work, in the same spirit of the original post. In truth, the true main thread that runs in main() is where all the iOS GUI work happens. Apologies for the confusing wording.

This is not only completely wrong, it's dangerously wrong. It is in fact wildly unsafe to touch the GUI from anything except the main thread. It's all the non-UI stuff that you should shove onto another thread.

Depends on what you call "main thread" - maybe he's saying worker thread that's doing the "main code" shouldn't be doing GUI

In other languages / frameworks, "main thread" may have flexible semantics, but in the land of iOS, UIKit defines the term "main thread" to have one specific meaning.

Nope, the term "main thread" is very explicitly defined by both iOS and OS X. Not only in all the frameworks (e.g. NSThread, NSRunLoop, etc. all explicitly define "main thread"), but even at the system level. OS X and iOS have a pthread function `int pthread_main_np(void);` that returns non-zero if the current thread is the main thread (meaning the initial thread that the application was launched with), and that is the thread that all UIKit (iOS UI) and AppKit (OS X UI) code must be running on.

So... GUI work goes on its own thread, however that works out

This is backward. Since UIKit is single threaded, the main thread must work on GUI: the best practice is that nothing except GUI work should happen there.

You're not being charitable enough to the comment... you two are in completely agreement with one another if you only changed the meaning of the word "main". It's clear the grandparent meant "the thread that's doing the work."

It's really difficult to get to that meaning, because "main thread" is what you call the thread where main() is invoked and which is where all the GUI calls must happen. You can't use a common term in context to mean something different from its common meaning and expect people to follow.

And yet it was perfectly obvious what was meant. If you just assume the person who made the comment is not stupid/rambling (difficult concept, I know...) it is not difficult to get the meaning at all.

You say it was perfectly obvious, I say it's almost impossible for someone steeped in iOS development to understand any way other than the way I said. Even given a huge amount of charity to the poster, the best I can do is "I have no idea what they mean by this."

How come we have to give this person the benefit of the doubt to the point of understanding a term to mean its exact opposite, but you don't have to give us any of that?

I think it's just a "my environment" bias thing going. I don't work on iOS and I immediately understood what was meant by the comment. Of course, the "my environment" bias may also include a degree of the "other" is not as bright as me.

Thank you for this. I see now how my wording was unclear, but this is exactly what I had meant. Sorry for the confusing word choice.

Changing a fundamentally well-defined term (main thread, i.e. the one on which main() is called which is running the core event loop for the application process) to be an incorrect opposite is rather fundamental when one is explaining an iOS best practice.

except on iOS GUI thread kinda has "main" attached to it, main_queue

Not just iOS. Pretty much all UI frameworks frown upon doing heavy work on the main thread.

Same was true of Java. Sun called it the "AWT event dispatch thread." Any process that does computation or blocks on IO should run in a separate thread and periodically post updates to the UI via an event queue.

https://docs.oracle.com/javase/7/docs/api/java/awt/EventQueu...

> What you have to do is create a thread [...]

A thread? But that'll never scale!

you dont need a cluster to display GUIs.

You should think big. The cloud is the future of GUIs.

are you sure? it might be a really big screen!

It's Eclipse. It'll never scale regardless.

What do you want? a whole new process? That doesn't scale either. Come on.

What we need is to put this into a Docker container then parallelize the cloud instances using asynchronous message brokers enterprise

Enterprise-grade GUI

When I gave the Nexus Mod Manager a try a little while ago, I wondered how it managed to take 18 hours to copy a few hundred files from one directory to another - on a SSD. Wouldn't be surprised if this was at least part of it.

Nexus Mod Manager is impressively bad. The interface is insanely laggy; select a mod, wait a second, list starts to refresh, wait a second, list finishes refreshing, wait a second, the mod info shows up. It's really easy to do things by mistake because of the lagginess (and probably just generally poor quality of programming). It has multithreaded downloads, but even these are messed up. Every time I tried them about 50% of the downloads got corrupted.

Doing GUI calls is a notorious way to slow down apps.

Seriously. One notable Smalltalker sped up the compiler in VisualWorks this way. Yes, there is a compiler in Smalltalk, it just usually only compiles one method at a time, which had a lot to do with why no one noticed that printing notifications to the transcript took up most of the time. So for a bulk code load, turning off the notification sped up "compile time" a whole lot. In fact, the JIT-ed Smalltalk in VisualWorks actually outperformed the C/YACC implemented compiler in a different Smalltalk.

Someone needs to keep track of this stuff. Why do we keep making the same mistakes over the decades? (Insert famous Alan Kay quote here.)

Years ago had a similar albeit smaller discovery. Loading a flash application with a progress bar and setting the quality option to the lowest quality made the bar go faster.

I remember having a few tricks like that–I vaguely remember moving bits of the GUI for some apps off screen so they wouldn't get drawn and thus run faster.

> I sped up an app by a factor of 10x

Woah

> This particular app was an Eclipse Plugin

Ah ha ok so it just runs fairly slow now right? :)

Reply on news.ycombinator.com