Considering this as a feature request and making the status to Untriaged so that the issue would get addressed.

Thank you.

The following is a test script which opens a new window without the overhead loading the chromium binary, however its still slow. It looks like forwarding the arguments to the main thread is the slow down, because the printf added below appears on the console as fast as the window.

#!/bin/sh

# START to find JSON communiaction code process_singleton_posix.cc, see shell code below triggering it

# important tags to open window
# IDS_USED_EXISTING_BROWSER
# IDC_NEW_WINDOW


# using this patch and the shell script makes the line print as fast as the
# window, so I think that forwarding the args to the main thread is the slow
# down.

# diff -r ./chrome/browser/process_singleton_posix.cc /tmp/chrome-orig/chromium-61.0.3163.100/chrome/browser/process_singleton_posix.cc
# 633d632
# <   printf("ProcessSingleton::LinuxWatcher::HandleMessage -> parent_->notification_callback_.Run\n");

SOCKET=~/.config/chromium/SingletonSocket

if [ -f "$SOCKET" ]; then
  {
  echo -e "START\0$(pwd)\0"
  for arg in "$@"; do
    echo -e "$arg\0"
  done
  } | nc -U $SOCKET
else
  exec chromium "$@"
fi

The following patch with previous .sh script shows the following timings
shows timings:

1509046600,4094650745 got start token 
1509046600,4094829559 PostTask 
1509046600,4095969200 ProcessSingleton::LinuxWatcher::HandleMessage -> parent_->notification_callback_.Run 

the console message appear as fast as the window, but delayed. So I think that
reading from the 

socat - UNIX-LISTEN:/tmp/p
echo x | socat - UNIX-CONNECT:/tmp/p
=> instantly shows x.


diff --git a/chrome/browser/process_singleton_posix.cc b/chrome/browser/process_singleton_posix.cc
index b8df920..cc2592f 100644
--- a/chrome/browser/process_singleton_posix.cc
+++ b/chrome/browser/process_singleton_posix.cc
@@ -101,6 +101,15 @@
 #include "ui/views/linux_ui/linux_ui.h"
 #endif
 
+
+#include <sys/time.h>  
+
+double mytime(){
+  struct timeval t1;
+  gettimeofday(&t1, NULL);
+  return t1.tv_sec + ((double) t1.tv_usec) / 1e6;
+}
+
 using content::BrowserThread;
 
 namespace {
@@ -630,6 +639,7 @@ void ProcessSingleton::LinuxWatcher::HandleMessage(
   DCHECK(ui_task_runner_->BelongsToCurrentThread());
   DCHECK(reader);
 
+  printf("ProcessSingleton::LinuxWatcher::HandleMessage -> parent_->notification_callback_.Run %.10f\n", mytime());
   if (parent_->notification_callback_.Run(base::CommandLine(argv),
                                           base::FilePath(current_dir))) {
     // Send back "ACK" message to prevent the client process from starting up.
@@ -690,6 +700,7 @@ void ProcessSingleton::LinuxWatcher::SocketReader::
     CleanupAndDeleteSelf();
     return;
   }
+  printf("got start token %.10f\n", mytime());
 
   std::string str(buf_, bytes_read_);
   std::vector<std::string> tokens = base::SplitString(
@@ -713,6 +724,7 @@ void ProcessSingleton::LinuxWatcher::SocketReader::
   tokens.erase(tokens.begin());
 
   // Return to the UI thread to handle opening a new browser tab.
+  printf("PostTask %.10f\n", mytime());
   ui_task_runner_->PostTask(
       FROM_HERE, base::BindOnce(&ProcessSingleton::LinuxWatcher::HandleMessage,
                                 parent_, current_dir, tokens, this));


So what is causing the delay reading from the socket?

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!