Jump to content


Level 2
  • Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About LukeB

Profile Information

  • Subscription

Recent Profile Visitors

1,629 profile views
  1. I have a 2018 iPad Pro and I am also experiencing these slowness issues. A note-taking app should not be so slow on such a powerful device. I do have a number of notes and I excerpt out of books so some of the notes can contain much text, but the computing power inside a 2018 iPad Pro is enormous. Combined with other bugs (old and new), I am seriously considering switching to something else which works across iOS and Windows. As best I can tell, Evernote spends most of its developer time on large businesses, and so their concerns matter much more than ours.
  2. I am having this problem as of updating to iPad iOS 14 and then updating Evernote. I copy out excerpts from books and thus have fairly long notes; since there's no easy way to scroll to the end of a note, I put something like "XXX" at the end of the note, so I can search for it in order to scroll to the bottom of the note. This no longer works, which is rather frustrating! This is also true for shorter notes when I search for content within them.
  3. My note doesn't contain "https://evernote.com"; it contains "https://www.evernote.com" and "evernote:///view". I wrote code to easily see the HTML code for contents on the clipboard; I just examined one of my oldest old green links and it's https://www.evernote.com. So, it appears that DTLow incorrectly diagnosed the problem. As to the sequence of operations you specify, Here's precisely what I did, from left to right: When I did that, the link produced was https://www.evernote.com/shard/s6/…, as I specified in the OP. Can you confirm that (i) you are running Evernote on iOS; (
  4. To reproduce: in Evernote 8.12 for iOS (released 2018-05-18) go to any note tap the person icon with a plus sign tap "More sharing options" tap "Copy internal link" tap "Done" paste from the clipboard into a different note the result is something like https://www.evernote.com/shard/s6/… Note that DTLow reported this, but the problem (on iOS) isn't actually that it is a web link vs. Evernote link (evernote:///view/…); I can click on the ugly link and be taken back to the appropriate note on my iPhone and Windows machine ( The prob
  5. This is a ridiculous amount of added margin: Surely Evernote could at least present a checkbox in settings for whether to display that margin. Even if it means that the table config UI is screwed up when the margin is hidden, it'd remove a massive inconvenience for the great number of users who never/rarely use tables. I would rather not be permanently stuck on an older version of Evernote in order to avoid this margin.
  6. Just a warning: last time I checked (sometime in 2016), inter-note links will not be maintained with imports, as the GUIDs for the notes themselves are not exported. Hopefully this has changed, but sadly I doubt it. One solution would be to put a note link to the note itself in the beginning of every note (perhaps via some automation utility) pre-export, doing search/replaces after import. But if you don't have the right skills to do this, it would be quite onerous.
  7. Suppose I copy a note link and paste it into another note. As long as there is some sort of text on the same line before the current cursor location, a space will be added. Here are three examples; the vertical bar represents the cursor location and the second line shows the result of the paste. | Note Link a| a Note Link b | b Note Link Suffice it to say that this is obnoxious behavior. (Especially the third example.) Not only do I link my notes together quite a lot, but I also have an AutoHotkey script which adds red underlining to selected text and can be triggered via whatever ho
  8. I don't see this as being off-topic in any way. The resulting impression people have of how important this performance problem is will impact how much attention the performance problem gets. For those actually experiencing this problem, we want more attention. For people like you who aren't experiencing this problem, you perhaps want less attention paid to this issue, because there are bugs and/or new features which would benefit you, competing with this performance problem. First, "professional experience" ≠ "mystic reason". Second, I have presented a very important fact (whether
  9. You are welcome to deny that long experience with software development gives me expert knowledge in this topic, declaring the matter "opinion". However, this does not make what you say true. There are objective truths in this realm. I gave you an existence proof: prior to a certain version, Evernote performed very well with long notes. We could look at the amount of computation required for "a large, complex, web page" and compare it to 90 KB notes which are mostly text with very little formatting. I did a force-refresh on page one of this thread and Google Chrome's Web Developer T
  10. If I were to hazard a guess, I'd say Kensington London rejects the reasoning you have expressed here; I do as well. I wrote my first line of code over twenty years ago and am well-aware of the progress in computational power since. Your argument here may work for ten years ago, but it is completely obsolete, today. This is clearly demonstrated by the fact that Evernote Mac did not always have the performance problem identified in this thread. It was introduced. Now, perhaps the performance prior to the offending update was a spurious boon and EN folks never intended that, but I think most peop
  11. I did not notice a difference when I turned it off (which I did a long time ago). The reason this is probably the case is that Context searching likely depends on the same indexing functionality which gives you better search in Evernote. Alternatively, perhaps turning it off only affects the UI and not underlying computation. There are two different general categories of high CPU usage. One is "one-time", like re-indexing a database—like switching from a version with "dumb" search to one based on fancy indexing. Another is the high CPU usage which accompanies slowness like is well-documen
  12. This is not the case; before a particular version, Evernote was plenty fast with large notes. The slowdown started around the time that better search was introduced and the display of "Context". Perhaps it was precisely the addition of this feature which caused the problem. Note that what is perceived as slowness on large notes will still take inordinately much processing power on smaller notes, which means that Evernote has a battery usage problem. I quickly searched and found the forum threads High cpu usage and very poor performance (Windows) and Evernote Mac 6.0.5: 100% CPU Utilization
  13. This issue is becoming increasingly frustrating. It reliably happens when I am editing large notes (e.g. 79.0 KB, 10,817 words, 67,575 characters, no images). I live in SF proper and I know there is an Evernote office complex nearby along SR 101. Would it be possible for me to come in, have you install a debugger/profiler, and look at the problem in action? Let me reiterate. This slowness is making Evernote unbearable for my use. I really do like what Evernote does, but this slowness is increasingly unacceptable. Note that I am a paying customer.
  14. I wonder if continuously indexing a note while it is being edited, whether for context or search (or perhaps the same indexing for both), is at all responsible for this. Do you suggest anything better than OS X's "Activity Monitor" which I could use to try and see whether the slowness is due to CPU, memory, or disk? I'm pretty sure it's not network. I used to be a Windows guy and perfmon was awesome; I haven't investigated good alternatives on OS X. I use iStat Menus for global indicators, but they've proven insufficient.
  15. I have since noticed that typing (and other mentioned operations) sometimes speeds back up to normal, during e.g. typing up sections from a book. Perhaps a garbage collection takes place? Note that performance degrades again.
  • Create New...