Real Basic - Produces Sluggish, Unusuable Code!

Intimidated · **Joined:** Mon Jan 01, 2007 9:30 pm **Posts:** 50

Re-raising an old thread.

Quote:

I can write slow, unusable code when I misuse the .NET APIs too. Most of the time it's not the tool that causes slow code, it's not understanding how to properly use the tool that causes slow code.

Aaron, This is extremely arrogant. RealBASIC DOES produce extremely slow applications when compared to other software.

I've just tried Steve's example above with RB2008r2. It takes over two minutes to scan a 3,000 item folder (on a USB hard drive). VB6 does this in 5.3 seconds.

I've seen you take the "use the win32api" approach a number of times. But that completely defeats the point of using RealBASIC.

If I want to use the win32 API for every operation I will code in C. I choose RealBASIC because of simplicity, rapid development, and cross platform compatibility.

In fact, using the API as indicated above will eliminate the cross platform bonus of RealBASIC completely, so I really don't understand why anybody would actually choose to use your software.

Please, fix RealBASIC. It's tragically slow. Or hire the monkeybread guy to fix your code and add some decent functionality.

harriew · **Posted:** Tue Jul 01, 2008 2:34 pm

What about the step of setting the visible property of the Listbox to false before the start of the loop and back to true after the end of the loop. I have seen that help considerably in the speed improvement category.

One last thing, when writing code to traverse folders of the sort presented here one should always use TrueItem rather than Item so that aliases, and the windows equivalents are not resolved.

pregan · **Posted:** Tue Jul 01, 2008 2:58 pm

My Simple Cataloger app just blew through 8000+ files and folders and spit out a text file of every property within 9 seconds. I haven't changed the code in two years. I use no pragmas and no plug-ins. Just a dead-simple, carefully-crafted method.

Code:

Sub ListItems(theItem as FolderItem)
  dim mItemCount, thisItem as Integer
  dim thisLine as Integer
  dim currentItem as FolderItem
  mItemCount = theItem.count
  for thisItem = 1 to mItemCount
    if DataMgr.CO_01_ResolveAliases = true then //Resolve Aliases?
      currentItem = theItem.Item(thisItem)
    else
      currentItem = theItem.TrueItem(thisItem)
    end if
    if currentitem <> nil AND currentItem.exists = true then //a quick NilObjectException Check
      if currentItem.Directory = true then //check for recursion
        if SortFolderFile(currentItem) = true AND SortInvisible(currentItem) = true then
          CatalogItem(currentItem)
        end if
        if SortPackage(currentItem) = true then
          ListItems(currentItem)
        end if
      else
        if SortFolderFile(currentItem) = true AND SortInvisible(currentItem) = true then
          CatalogItem(currentItem)
        end if
      end if
    else
      DataMgr.UpdateStatusField(LanguageMgr.ErrorListItemsNilObjectExceptionCheck + currentItem.AbsolutePath)
    end if
  next
End Sub

Sub CatalogItem(theItem As FolderItem)
  //Default Data Points
  if DataMgr.CO_DP_Name = True then
    CO_DP_NameArray.Append theItem.Name
  end if
  
  if DataMgr.CO_DP_Path = True then
    CO_DP_PathArray.Append theItem.AbsolutePath
  end if
  
  if DataMgr.CO_DP_Size = True then
    CO_DP_SizeArray.Append theItem.Length //need to convert this to MB and GB when appropriate
  end if
  
  if DataMgr.CO_DP_CreatorCode = True then
    if theItem.MacCreator <> "" then
      CO_DP_CreatorCodeArray.Append theItem.MacCreator
    else
      CO_DP_CreatorCodeArray.Append "****"
    end if
  end if
  
  if DataMgr.CO_DP_TypeCode = True then
    if theItem.MacType <> "" then
      CO_DP_TypeCodeArray.Append theItem.MacType
    else
      CO_DP_TypeCodeArray.Append "****"
    end if
  end if
  
  //Other Data Points
  if DataMgr.CO_DP_Type = True then
    CO_DP_TypeArray.Append theItem.Type
  end if
  
  if DataMgr.CO_DP_CreationDate = True then
    CO_DP_CreationDateArray.Append theItem.CreationDate
  end if
  
  if DataMgr.CO_DP_ModificationDate = True then
    CO_DP_ModificationDateArray.Append theItem.ModificationDate
  end if
  
  if DataMgr.CO_DP_Locked = True then
    CO_DP_LockedArray.Append theItem.Locked
  end if
  
  if DataMgr.CO_DP_Visible = True then
    CO_DP_VisibleArray.Append theItem.Visible
  end if
  
  if DataMgr.CO_DP_DisplayedName = True then
    CO_DP_DisplayedNameArray.Append theItem.DisplayName
  end if
  
  if DataMgr.CO_DP_Owner = True then
    CO_DP_OwnerArray.Append theItem.Owner
  end if
  
  if DataMgr.CO_DP_Group = True then
    CO_DP_GroupArray.Append theItem.Group
  end if
  
  if DataMgr.CO_DP_Permissions = True then
    CO_DP_PermissionsArray.Append theItem.Permissions
  end if
  
  itemCount = itemCount + 1
  
End Sub

Anyone can write that nonsense (and the proof is in the number of file catalogers that exist already. I wrote it and sold it as an exercise for the real work I'm doing). I was a rank beginner when I wrote that, but I have yet to make it faster no matter what I do to it. My point is not to too my own horn but to make the point that usually it is the programmer that's the problem and not the language. What Aaron said isn't arrogant, it's an immutable law of programming that applies to all languages. RB isn't perfect but then neither are the rest of them.

Intimidated · **Joined:** Mon Jan 01, 2007 9:30 pm **Posts:** 50

No, i'm sorry. Yes, often it is the programmer's fault that code ends up slow.

However..

Code:

sub recurse(fi as FolderItem)

  #if not DebugBuild then
    #pragma BackgroundTasks false
    #pragma BoundsChecking false
    #pragma NilObjectChecking false
    #pragma StackOverflowChecking false
  #endif

  Dim i As Integer
  Dim iMax As Integer = fi.Count
  Dim thisFile as FolderItem
  for i = 1 To iMax
  thisFile = fi.TrueItem( i )
  if thisFile.Directory Then // no need to test Boolean against True
    recurse(thisFile)
  else
   dim strFileName as string = thisFile.Name
   if right(strFileName,4)=".avi" then
    filelist.append strFileName
  end if
  end if
  next
end sub

The exact translation of this code runs over 500 times faster on visual basic six.

THAT is not a programmer fault.

pregan · **Posted:** Tue Jul 01, 2008 3:56 pm

Quote:

The exact translation of this code runs over 500 times faster on visual basic six.

<thinking_out_loud> There has to be something else going on elsewhere in the application that's causing the slow down. My method does more calculations that yours does yet yours takes longer. Mine is run from a thread if that makes any difference. Maybe take the

Code:

dim strFileName as string

out of the loop? </thinking_out_loud>

timhare · **Posted:** Tue Jul 01, 2008 4:58 pm

No, it's a documented fact that FolderItem.Item() and .TrueItem() can run significantly slower on Windows due to the constraints of the api, depending on how you use them. The underlying problem is that the windows api does not allow indexing of the directory entries. To reach item #100, you start at 1 and call Next 99 times. RB cannot predict how you are going to use the information, so it's forced to start fresh each time you call Item(). Add to that the fact that entries may be added and removed between calls to Item(), and RB has chosen the safest path.

RB *could* return an array of FolderItems, but that would be unnecessary bloat on the other platforms. Since there's a perfectly good api to iterate over the directory already available, it hasn't gotten much pressure. A feature request for

Function FolderItems.Items() as FolderItem()

would be a reasonable approach.

(I assume Philip's results are from the Mac, where the problem doesn't exist)

Tim

pregan · **Posted:** Tue Jul 01, 2008 5:10 pm

Quote:

(I assume Philip's results are from the Mac, where the problem doesn't exist)

Yes.

timhare · **Posted:** Tue Jul 01, 2008 5:26 pm

Quote:

Function FolderItems.Items() as FolderItem()

Aaron posted such a function on the forums recently. But thinking about it further, a function for NextItem and NextTrueItem would be even better. That would conform to the api better, and not require using up all the memory for an array of folderitems.

Remember, FolderItem began life on Mac, where the api is to use an index. When they ported to Windows, they used a mechanism that produced the same result, so code written on one platform would work on the other. Unfortunately, you pay a performance penalty on Windows, under certain conditions.

Whatever the solution, you're probably still going to end up with conditional code to do it one way on one platform and a different way on the other, so why not cut out the middle man and call the api directly? Your assertion that calling platform-specific code "defeats the point of using RealBasic" is complete rubbish.

Tim

Intimidated · **Joined:** Mon Jan 01, 2007 9:30 pm **Posts:** 50

Quote:

so why not cut out the middle man and call the api directly?

Why not just code in C?

Why do people use RealBasic instead of a lower level language?

- Simple cross platform deployment
- Speed of development

I have already been forced to use the API in many instances where RealBASIC has fallen short; every API call I include makes it less and less beneficial to use RB.

That was, of course, until I bought the MBS plugin. The monkeybread plugin makes RealBASIC what it SHOULD be.

The MBS filelistmbs class is called in EXACTLY the same way, and is lightning fast (and, incidentally, it works perfectly on all platforms with virtuall no overhead). It really does just show you how badly coded RealBASIC is.

So, I have a choice between:

- Use the MBS plugin and deal with additional memory usage of my application
- Code this using API's for each platform, which will take a great deal of time, thereby nulling the reason I use RB

timhare · **Posted:** Tue Jul 01, 2008 6:27 pm

Quote:

every API call I include makes it less and less beneficial to use RB.

I'm sorry, but I don't understand that statement at all. And how is calling a declare using a "lower level language"? Declare is an RB keyword, isn't it?

To me, the ability to call a system API makes RB much, much more powerful.

Tim

Karen · **Joined:** Fri Sep 30, 2005 8:53 am **Posts:** 810

timhare wrote:

Quote:

every API call I include makes it less and less beneficial to use RB.

I'm sorry, but I don't understand that statement at all. And how is calling a declare using a "lower level language"? Declare is an RB keyword, isn't it?

To me, the ability to call a system API makes RB much, much more powerful.

Yes I agree BUT but his point is you should not have to do it so OFTEN to great good performance and I agree with that too .....

If you have to find and learn the platform API's you will spend a heck of lot more time than just using the Xplatform RB framework ... so much so that you might be better off a platform specific product where you don't need to do that so often.

Yes you can work around RB's issues that way, but work arounds add complexity, coding time and code support issues.

- Karen

npalardy · **Posted:** Tue Jul 01, 2008 7:27 pm

If you want to make a cross platform product that appears to be no different than any other then you really might need to delve into the declares on each platform
While RB can insulate you from some of that it won't cover 100% of it

Mars Saxman · **Joined:** Wed Sep 28, 2005 6:06 pm **Posts:** 274

Quote:

RealBASIC DOES produce extremely slow applications when compared to other software.

Your example demonstrates that one specific class in the REALbasic framework performs poorly at one specific task on one specific platform. If that is the only task you need to perform, then I suppose one could arrive at the generalization "extremely slow applications", but your specific case does not justify a general rule.

-Mars

Kuzey · **Joined:** Fri Sep 30, 2005 7:20 pm **Posts:** 828

Oooh...I didn't know about the slowness of folderitems on Windows...great information.

I never used declares before and have little experience on a PC, is there an example of this Windows declare to bypass the folderitem.item in RB.

Oh...I used a shellscript

Code:

"dir /b /s"+" "+f.shellPath

in the past, but that was slow as well. I would split the result into an array and then use ubound to add each item to a listbox...but that was a few years back.

Kuzey

pregan · **Posted:** Wed Jul 02, 2008 6:46 am

Quote:

If you want to make a cross platform product that appears to be no different than any other then you really might need to delve into the declares on each platform
While RB can insulate you from some of that it won't cover 100% of it

However, one could argue that the use of declares flies in the face of RB's "ease of use" paradigm. I'm no novice, but some functions I've looked at require a lot of surprisingly complex code. If you guys know what the API call is, you know how it works, you know it works better than what you have, and it's a function that's used by just about everyone, then what in the world are you waiting for? A bug report?

REAL Software Forums

Real Basic - Produces Sluggish, Unusuable Code!

Who is online

	REAL Software Forums The forum for REAL Studio and other REAL Software products.
[ REAL Software Website \| Board Index ]