0

I am trying to open a pdf file (using default pdf reader) from a Python script in which user chooses file from GUI. However, it takes too long to open the file after GUI.

  • Python: 3.8.5
  • PySimpleGUI: 4.28.0, Tkinter Port
import time
import os
import subprocess

import PySimpleGUI as sg

def without_gui_input():
    return input("File: ")

def with_gui_input():
    abs_path = sg.popup_get_file("Please select a file", initial_folder=".")
    return os.path.relpath(abs_path)

file_path = with_gui_input()  # without_gui_input()

start = time.time()
subprocess.call([file_path], shell=True)
end = time.time()
print(f"Took {end-start} seconds.")
  • Without GUI: 0.4 second
  • With GUI: 15.4 seconds

I could not locate the problem. I thought maybe GUI closing operation takes long but I tried to get input from a window (not popup) that is not closed after it gets input but results were the same. How can I speed up this process?

Note: I need to use call() instead of Popen() to ensure that the file is opened.

Edit: I can use Popen().communicate() instead of call() but results are the same. Both are blocking operations.

alercelik
  • 615
  • 7
  • 11
  • I couldn't reproduce your issue, I tried your code as-is and "with GUI" tells me it "Took 0.0021638870239257812 seconds.". Without GUI a similar number. Are you picking the same file? Are you using your current code? maybe you placed the "start" line before asking the user and so measured your human time of finding the file. – Marc Sances Aug 17 '20 at 06:57
  • @MarcSances interesting.. I executed the code above, time() calculates only file opening time. I entered the same file name for both with and without gui. – alercelik Aug 17 '20 at 07:02
  • Could be some issue with PySimpleGUI or something. If by any chance you're using PyCharm Professional, you can run with the "profile" option (Run > Profile). It will give you a nice output where you may be able to see what is causing the issue. – Marc Sances Aug 17 '20 at 07:05
  • @MarcSances, i mistakenly wrote Popen() in the code, now i replaced it with call(). Popen() works just as you told. Sorry for that. – alercelik Aug 17 '20 at 07:08
  • No difference. Tested both with and without GUI using ``subprocess.call`` and it still takes almost no time. – Marc Sances Aug 17 '20 at 07:09
  • I have tried several things like os.system() however all prodoced the same result for me – alercelik Aug 17 '20 at 07:32
  • Can you try something like reading a file instead of executing it, and see if that makes a change? – Marc Sances Aug 17 '20 at 07:45
  • The time is just the execution time of `file_path` passed to `subprocess.call()`, it is nothing related to which function you called to get the `file_path`. – acw1668 Aug 17 '20 at 07:47
  • @acw1668, that is the problem itself. After a GUI operation, `subprocess.call()` takes too long. However, after a simple `input()` it executes normally. – alercelik Aug 17 '20 at 07:53
  • Your posted code should not have such behaviour. Can you post one example of `file_path`? – acw1668 Aug 17 '20 at 07:55
  • @MarcSances, i need that exact `subprocess.call()` or related blocking functions. non-blocking `Popen()` works normally without a problem. – alercelik Aug 17 '20 at 07:55
  • @acw1668, .py and .pdf file are in the same folder. I just pass "1.pdf" for input() for non-gui and gui converts the absolute path of selected file to relative path wrt cwd. Both gui and non-gui returns the same "1.pdf" – alercelik Aug 17 '20 at 07:59
  • If `file_path` is `1.pdf`, then the registered application (if any) for `PDF` file will be executed with `1.pdf` as its argument. How can the `conversion` program you mentioned be executed? – acw1668 Aug 17 '20 at 08:03
  • I send "ctrl + a" and then "ctrl + c" to the opened file. + I do not want to work with pdf reader libraries – alercelik Aug 17 '20 at 08:42

0 Answers0