Calibre very slow on a Windows7?

[johnwayneb]

First off, my test is completely valid. Let me simplify. Navigating the UI w/ svg icons is extermely slow and spikes my CPU usage stalling the app. Navigating the UI w/o (any) svg icons is fast and does not spike the CPU.

My concern is not with the load times of a 8kb file, but rather the render time of an svg icon. Your test proves nothing other than loading pngs is faster (which it should be). I am attempting to prove that the the render speed of svg icons is slow.

Secondly, I am not testing startup time. I am testing responsiveness of the UI.

How can you claim that this is specific to my hardware? I have tested this on 3 separate machines running 2 different operating systems. They all exhibit the same problem: the rendering of svg icons is slow.

I realize you would like to display icons in a variety of resolutions. So use pngs/ico/xbm files, svg textures are clearly too expensive.

Its unfortunate that you simply write this off as an isolated incident. I would gather that many user are experiencing this issue but not reporting it.

I do choose to ignore other telling me it works find on their machine, because that doenst help me actually solve the problem now does it.

Work for me! Is not a valid response when I have experienced that it doenst work on every machine I have tried it on.

I am more than happy to work towards a solution, when people stop claiming its a problem on my end and admit the software is faulty.

[kovidgoyal]

Sigh^2

Startup time for the GUI includes the time to render the icon. And incidentally for lots of icons, the SVG files are actually larger than their PNG equivalents.

What you seem unable to grasp is that the overhead for rendering SVG is very small, compared to the overhead for other things calibre does. The fact that it is larger for you, is an indication of something wrong on your systems.

[kovidgoyal]

Originally Posted by johnwayneb

How can you claim that this is specific to my hardware? I have tested this on 3 separate machines running 2 different operating systems. They all exhibit the same problem: the rendering of svg icons is slow.

Because it is not an issue for any one else.

I realize you would like to display icons in a variety of resolutions. So use pngs/ico/xbm files, svg textures are clearly too expensive.

Huh? Do you understand the difference between a vector and raster image format?

Its unfortunate that you simply write this off as an isolated incident. I would gather that many user are experiencing this issue but not reporting it.

You gather this using ESP?

I do choose to ignore other telling me it works find on their machine, because that doenst help me actually solve the problem now does it.

Let me paraphrase: "I choose to ignore other telling me it works because I am convinced I am right and everyone else is wrong and the fact that it doesn't work on my 3 machines is obviously more significant than that it works on 30 other machines."

I am more than happy to work towards a solution, when people stop claiming its a problem on my end and admit the software is faulty.

Good, I've committed code to the repository to switch to using raster icons as part of the experiment I did earlier, run from source code and see if that fixes it for you. At the moment I haven't decided whether I will stay with raster icons or switch back to svg, so your input will help me decide.

[johnwayneb]

So, according to you rendering PNG's is just as quick as rendering SVG's, i'm the one who doesnt understand the diff. between image formats, 95% CPU usage is very small overhead, you need a supercomputer with 10 processors to parse/convert some text files, and apparently every machine I can get my hands on suffers from the same issue...


Ok.
I give up.


Good luck to you sir... you need it.

[kovidgoyal]

Dont let the door hit you on the way out.

[DoctorOhh]

Originally Posted by kovidgoyal

Good, I've committed code to the repository to switch to using raster icons as part of the experiment I did earlier, run from source code and see if that fixes it for you. At the moment I haven't decided whether I will stay with raster icons or switch back to svg, so your input will help me decide.

Kovid implemented a possible solution for your unique situation (above) and to put it politely you chose to act like a child (below).

Originally Posted by johnwayneb

So, according to you rendering PNG's is just as quick as rendering SVG's, i'm the one who doesnt understand the diff. between image formats, 95% CPU usage is very small overhead, you need a supercomputer with 10 processors to parse/convert some text files, and apparently every machine I can get my hands on suffers from the same issue...
Ok.
I give up.
Good luck to you sir... you need it.

Over a million people use this program and somehow you have insight that the rest of us overlook?

Are you using a NAS to store your library? Since I live on the trailing edge of technology and don't have any problems it goes to reason that something in your environment is off kilter.

It's ashamed that you aren't willing to put in the time to test the code that Kovid changed to try and assist your situation. I don't understand why someone would go to all this trouble and then "give up" when a possible solution was offered for testing.

[Adoby]

Still. Calibre IS very slow. I dpn't believe I have any other program on my computer that is as demanding on my computer, as Calibre is.



I tried just starting and closing some "heavy weight" programs, and monitored CPU usage. OpenOffice Writer, Firefox and The Gimp all seem very modest in CPU-usage, when starting, compared to Calibre.

I suspect this is because Calibre relies to a large extent on code written in Python. While this means that development can progress at a close to neck breaking speed, it also means that the performance does suffer.

I can live with that. I don't mind waiting a few seconds longer for Calibre, than I wait for other programs. But others may become surprised, annoyed and confused when they discover that Calibre is the worst CPU-hog they use.

[solitaire]

I have been running calibre on Win 7 since V0.6.xx. Mine is a 64 bit setup on 2 machines and 32bit on my laptop. Processors range from 8 (16 with hyperthreading) on one machine, four on another and 2 on my laptop. RAM ranges from 12G on the 8 processor machine to 4G on the other 2.

The only problem that I have experienced was during installation (something to with cost), but even that has gone away with 0.7.17.

Never noticed any slow performance from the application itself (300 books). If anyone can tell me what info they would need from my setup, I would be happy to provide that seeing that I do not have the issue stated by johnwayneb.

[Starson17]

Originally Posted by Adoby

I suspect this is because Calibre relies to a large extent on code written in Python. While this means that development can progress at a close to neck breaking speed, it also means that the performance does suffer.

Kovid has stated that Calibre is currently optimized for development speed. It shows - Calibre is incredibly easy to develop and has the fastest cycle time of any program I use. It's a compromise I can live with. Speed during use is not ignored - there have been many speed improvements, but I like the current focus on development.

[cvkemp]

Not sure if anything changed but I have noticed that with 7.17 that calibre opens much faster than before.

[Adoby]

Originally Posted by Starson17

I like the current focus on development.

So do I. Interesting to update and see what has changed. I am amazed at the speed of releases. And the quality.

Calibre is a slowly spinning bullet in a high speed trajectory ...



... or something like that.

[jotekman]

johnwayneb: Dude. Seriously. Seriously?! You have a whole forum of people willing to help you, a fantastic program made just by the good graces of a guy who owes us nothing, you complain about it, he offers to try to help and fix it, then you become insulting, and he STILL offers to try to fix it, and you are insulting again? Wow. Ballsy you may be, but obviously lacking any sort of tact or social graces alltogether. Maybe if you were paying an inordinate amount of money for a specialized program just for you from a developer you would have the right to act like that, but you are just irritated that the program LOADS slow on YOUR particular systems. You might have tested it on 3 computers, well, what are the chances you have the same OS, or the same tweaks, or same programs installed on all of them? If none of that is true, then I guess you are just cursed by the gods for this particular program and its not for you. I might not be a dev or know how to fix the program, but I DO know computers and OS's and what runs GREAT on some OS's runs like crap on others. ESPECIALLY if you are using customized builds of something. I completely agree with Kovidgoyal. You burned up any goodwill you might have had in the beginning.
Ciao.

[GeoffC]

Kovid For what you have produced with Calibre and voluntarily, I salute you.


I have recently upgraded to 0.7.17 and HOLY MOSES in the bullrushes, this now loads up significantly faster than previous versions.

[kacir]

Originally Posted by Adoby

Still. Calibre IS very slow. I dpn't believe I have any other program on my computer that is as demanding on my computer, as Calibre is.

No other program, that you mention, is written in an interpreted language.
Each language has advantages and trade-offs. One of the disadvantages of interpreted languages is speed. On the other hand, Python is multi-platform (I LOVE running Calibre on Linux computer), facilitates fast development (so we see new and exciting features much, much more often than, for example, Open^H^H^H^HLibreOffice users) and enables developers to implement kick-ass Regular Expressions searches and replacements throughout the program relatively easy.

I have been using Calibre on and off since very early versions, even before it was called Callibre. I just loved the fact that I could run LibPRS-500 on my Linux comp instead of running clunky, quirly and weird Sony ... aehm ... "professionally written" library software and having to boot into Windows.

Recently I have started to use Calibre to manage my collection of books, texts, articles and other stuff. Its start IS slow, the interface isn't exactly my cup of tea (it is better than previous versions, or I got used to it ;-) ), but it features so many tricks, options, shortcuts that I keep discovering that I am constantly amazed by the work that was done.

I have found one aspect of the program very slow. Conversion process. When I start conversion of a *.lit book, the process takes many minutes. Kovid told me that this is normal, and that his convertor does more things than other convertors, so I simply started to use an external program lit2epub, which is free and lightning fast. No problem here. I only wish I could tell Calibre to use lit2epub convertor for converting from lit to epub instead of the default one (which is a stand-alone program anyway).

[itimpi]

Originally Posted by kacir

I have found one aspect of the program very slow. Conversion process. When I start conversion of a *.lit book, the process takes many minutes. Kovid told me that this is normal, and that his convertor does more things than other convertors, so I simply started to use an external program lit2epub, which is free and lightning fast. No problem here. I only wish I could tell Calibre to use lit2epub convertor for converting from lit to epub instead of the default one (which is a stand-alone program anyway).

I have found this seems to depend on the quality of the LIT file. On my system (2ghz single-core) the vast majority convert in under a minute. The ones that take longer are almost invariably ones that have been converted from other formats and that (on closer examination) contain lots of spurious tags at the HTML level. This seems to be getting better as time goes by as these problematical LIT files are becoming rarer, or are available as HTML format as well which nearly always converts faster and with better results.